Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XHTML Club

xhtml.club

Post reply on HN
Print view View original

71–80 of 131 posts

Re: XHTML Club

#71

Post by notnullorvoid »

jraph wrote: post #64
notnullorvoid wrote: post #55

I highly recommend everyone involved in web development to read at least a small proportion of the horrors that are the HTML parser specification. It will leave you yearning for the return of XHTML. Or you could also read web proposals where the reason for avoiding the ideal implementation is complication of updating HTML parser rules. Or attempt to use the web features that are already hindered by the HTML parser (c…

> It will leave you yearning for the return of XHTML. …or be grateful you can just use an existing HTML5 parser that hides all this stuff to your innocent eyes :-)

Grateful in part, but I can't help to think that if there was refusal to build parsers for an outlandish spec in the first place then we'd have fixed the problem by now.

Using existing parsers only hides the poor design up to a point.

Re: XHTML Club

#72

Post by jraph »

notnullorvoid wrote: post #71
jraph wrote: post #64

Earlier quoted context omitted.

> It will leave you yearning for the return of XHTML. …or be grateful you can just use an existing HTML5 parser that hides all this stuff to your innocent eyes :-)

Grateful in part, but I can't help to think that if there was refusal to build parsers for an outlandish spec in the first place then we'd have fixed the problem by now. Using existing parsers only hides the poor design up to a point.

I'm conflicted on this.

I mostly agree with the sentiment, I'd rather have simple parsers and sensible specs, but I'm also happy they do whatever it takes not to break anything (well, they are breaking XSLT…)

Re: XHTML Club

#73

Post by jraph »

PaulHoule wrote: post #49
jraph wrote: post #39

Earlier quoted context omitted.

You could have some client side JavaScript handle your for nodes as well. That's how I imagined what OP described actually. > Nobody uses PHP this way any more though Well… I have bad news. I do, for one :-)

I ask you then: (1) how do you deal with the template that surrounds a large number of pages on a site? (2) how do you deal with the fact that the average web form might want to display something different based on the form contents (e.g. redraw the form if there's an error, draw something different on success?) (3) do you write anything that returns JSON or other results for AJAX or web services?

(1) What about it? (note that I don't manage websites with a large number of pages)

(2) It's easy to add if conditions that test $_GET, $_POST or $_REQUEST display different things depending on what was submitted

(3) Not often (but have in the past, and will probably have to soon in a personal project). What issue are you anticipating?

Re: XHTML Club

#74

Post by strogonoff »

PaulHoule wrote: post #70
strogonoff wrote: post #61

Earlier quoted context omitted.

That is a good point, if you consider XSD then that is an XML connection, it starts to become a bit complicated and I see why people start to dislike it. I forget about that because to me it’s just about the idea of a graph, which is otherwise quite elegant. Why not have a graph type-free with just string literals; much richer information about what kind of values go where can be provided through constraints, vocabul…

Because the semantics of numbers and dates matters. It's absurd that JSON defines numbers as strings and has no specification for dates and times. I believe we lose a lot of small-p programming talent (people who have other skills who could put them on wheels by "learning to code") the moment people have the 0.1 + 0.2 != 0.3 experience. Decimal numbers should just be on people's fingertips, they should be the default…

> Because the semantics of numbers and dates matters.

Type semantics is only a small part of what is needed for systems and humans to know how to adequately work with and display the data. All of that information, including the type but so much more, can be supplied in established ways (more graphs!) without having to sprinkle XSD types on your values.

For example, say you have a triple where the object is a number that for whatever good reason must lie between 1 and in 0.1 increments. Knowing that it is a number and being able to do math on it is not that useful when 99% of math operations would yield an invalid value; you need more metadata, and if you have that you also have the type.

Besides, verbatim literal, as obtained, is the least lossy format. The user typed "2.2"—today you round it to an integer but tomorrow you support decimal places, if you keep the original the system can magically get more precise and no one needs to repeat themselves. (You can obviously reject input at the entry stage if it’s outlandish, but when it comes to storage plain string is king.)

Re: XHTML Club

#76

Post by jraph »

radicalethics wrote: post #69
direwolf20 wrote: post #38

Earlier quoted context omitted.

That's basically the design of PHP with different syntax. Nobody uses PHP this way any more though — people treat it like Python or Node and write the entire codebase inside a big JSP is similar with different syntax again — nobody uses JSP either I think ASP too but I never used that

If HTML was never able to be the full solution, then I guess if I had to expand on where I'm going, then what the heck are we even doing with this html thing? Either MAKE IT like PHP, ditch it, or do something, anything.

HTML is perfectly able to do what it was designed for: mark up documents.

There still needs to be something like HTML even when you have PHP: PHP is something you run on the server and it still needs to output something to the client in some format, and HTML is adequate for this.

The heck we are doing with HTML is taking it for building client apps. But even then, you now have UI toolkits that mimic this model: QML, whatever XML format Android has to design UIs, etc.

Re: XHTML Club

#77

Post by chrismorgan »

jraph wrote: post #60
chrismorgan wrote: post #57

Earlier quoted context omitted.

The things that are invalid should all have defined behaviour. For example, a is not allowed to contain two form controls, but is defined as applying to the first such control. As far as parse errors is concerned, https://html.spec.whatwg.org/multipage/parsing.html#parse-er... says: > This specification defines the parsing rules for HTML documents, whether they are syntactically correct or not. Certain points in the…

> The things that are invalid should all have defined behaviour 100% agree. And then I guess the philosophical question is "What's invalid when everything is defined?"

The idea of almost all of HTML’s errors (parsing and conformance) is that they indicate likely errors (though it’s definitely quite possible to deliberately skirt the edges, e.g. content=width=device-width,initial-scale=1).

Re: XHTML Club

#78

Post by PaulHoule »

jraph wrote: post #73
PaulHoule wrote: post #49

Earlier quoted context omitted.

I ask you then: (1) how do you deal with the template that surrounds a large number of pages on a site? (2) how do you deal with the fact that the average web form might want to display something different based on the form contents (e.g. redraw the form if there's an error, draw something different on success?) (3) do you write anything that returns JSON or other results for AJAX or web services?

(1) What about it? (note that I don't manage websites with a large number of pages) (2) It's easy to add if conditions that test $_GET, $_POST or $_REQUEST display different things depending on what was submitted (3) Not often (but have in the past, and will probably have to soon in a personal project). What issue are you anticipating?

(1) It's a problem if you have 2 or 3 (never mind N where N is large) different web pages that have the same stuff at the top of the bottom. I mean you can have

  
  ... body ...
but...

(2) ... in either case it is just as easy to write
where you have the option of putting headers on before you include header.php, showing a different header or footer conditional, etc. This approach is structurally stable and scales with the complexity of your application no matter what you're doing...

(3) ... for instance say you want to write a page that might return a different format depending on the headers, the router can return JSON if that is called for, or XML if that is called for, or HTML inside the site's global template if that is called for.

Re: XHTML Club

#79

Post by jraph »

PaulHoule wrote: post #67
embedding-shape wrote: post #3

Earlier quoted context omitted.

I dunno, you're being pedantic :) Yes yes, the name clearly ends up "Markup Language" so yeah, with a very strict definition of programming languages, HTML is not one of them. But if we use a broader definition, basically "a formal language that specifies behavior a machine must execute", then HTML is indeed a programming language. HTML is not only about annotating documents or formatting, it can do things you expect…

One threshold is "can you write a program that might not complete?" You can't in SQL, which makes it less of a programming language than, say, FORTRAN. If you look at the HTML 5 spec it is clear that it's intended to be a substrate for applications. The HTML 5 spec could be factored into a specification of the DOM, specification of an x-language API for the DOM and a specification for a serialization format as well a…

> If you look at the HTML 5 spec it is clear that it's intended to be a substrate for applications

That's the saddest thing I've read today.

(arguably not a terribly sad day)

Re: XHTML Club

#80

Post by jraph »

PaulHoule wrote: post #78
jraph wrote: post #73

Earlier quoted context omitted.

(1) What about it? (note that I don't manage websites with a large number of pages) (2) It's easy to add if conditions that test $_GET, $_POST or $_REQUEST display different things depending on what was submitted (3) Not often (but have in the past, and will probably have to soon in a personal project). What issue are you anticipating?

(1) It's a problem if you have 2 or 3 (never mind N where N is large) different web pages that have the same stuff at the top of the bottom. I mean you can have ... body ... but... (2) ... in either case it is just as easy to write where you have the option of putting headers on before you include header.php, showing a different header or footer conditional, etc. This approach is structurally stable and scales with t…

I'll use (1) for when I have a restricted set of pages (say, the usual pages of a site, like home, contact, about ...); body is not in a separate file; and (2) when the number of page is dynamic, say, a site that displays recipes stored in markdown files.

(3) I don't know yet for sure how I'd do it today (I will soon normally), I suppose I would just write different scripts, that can call some shared code. For APIs, people expect something that looks like REST endpoints and I suppose I would return JSON or XML in REST endpoint, but the URL structure that looks good for REST wouldn't for a normal page.

Post reply on HN