It’s just data

Don't Break The Web

Input Element, Size Attribute:

References:


Don’t Break The Web

The point is that validation doesn’t have much to do with the principle?

Posted by Anne van Kesteren at

Don’t Break The Web

What’s broken? I can still type into both input boxes.

Posted by Dean Edwards at

Don’t Break The Web

The point is that validation doesn’t have much to do with the principle?

The validator implements the spec.

What’s broken? I can still type into both input boxes.

Hints:

Posted by Sam Ruby at

Don’t Break The Web

So your point is that HTML5 is not a strict superset of HTML4 minus the .diff you posted? Or that the size attribute should be part of the HTML5 specification? And that for either reason it is broken?

Posted by Anne van Kesteren at

Don’t Break The Web

Maybe I’m just being dumb but, I don’t see what’s broken. The spec will say how to render <input size=""> even if it’s considered non-conforming. The web won’t get broken by removing some elements or attributes from the language spec as long as UAs retain support. AIUI, “don’t break the web” is more about not introducing language-level changes that UAs cannot support without using a different codebase for HTML4 and HTML5, and about defining how all features, obsolete or not, are supposed to work in UAs, not about making HTML5 a strict superset of HTML<5.

(None of this should be taken as a position on the wisdom or otherwise of this specific change).

Am I missing your point?

Posted by jgraham at

Don’t Break The Web

“Don’t break the Web” has been clarified to “Support existing content”. A validator is not “content”, so the principle is not violated here.

Posted by mpt at

Don’t Break The Web

Existing content.

Background: there is a lengthy thread on public-html@w3.org whereby those that wish to eliminate b elements are painted as green eyed monsters who should be banished to the XHTML2 working group.

This position would make a lot more sense to me if it were consistently applied.

Posted by Sam Ruby at

Don’t Break The Web

I’m not sure that’s a fair characterisation of the arguments, although there has been a certain amount of confusion so maybe my view isn’t a better summary.

(first, I should note for pedants that there has been much more debate about i and em than b)

I think in general the people who have been pointed toward the XHTML2-WG have been those arguing for strict error handling for HTML documents. Since this is contrary to the point of the HTML-WG it seems reasonable to suggest that these people work with a group that is chartered aims in line with their own.

There is a significant overlap between the aforementioned group and the (larger) group of people who believe everything in HTML should be “semantic”. However the groups are not one and the same; for example Hixie belongs* to the latter group but not the former (despite this, it is clear he can be convinced of the need for what is generally considered non-semantic markup e.g. the <font> element in WebApps).

There is also a group of what I would term pragmatists; those who do not believe that semantic markup is intrinsically useful but believe it is a means to an end (where the end is e.g. more accessibile content, more useful search engines, etc.). For these people there is no inconsistency between including <i> in one place and excluding <input size=""> in another as long as a convincing justification can be made for the difference.

(The above categorisations are necessarily simplifications).

The WHATWG HTML5 spec is fundamentally a pragmatic spec so the inclusion or exclusion of various features has been based on their individual merits rather than some vision of cleansing the web of non-semantic markup. As a result, almost everyone (including the editor) objects to some or more of the spec but the difference you cite does not necessarily arise from inconsistently applied principles.

(I also think that there’s a much larger issue in the overall inefficiency of the HTML-WG; I am very worried we will never get as far as speccing useful new features because of the time spent on semantic navel gazing).

Posted by jgraham at

Don’t Break The Web

I think in general the people who have been pointed toward the XHTML2-WG have been those arguing for strict error handling for HTML documents.

I think that’s potentially a mis-characterization.  Another equally valid (or equally invalid, if you prefer) characterization would be that there are people who simply want to document what correct behavior would be for correct documents and go no further, and another set who would like to bite off the more larger scope of specifying how every possible input (conforming or otherwise) is to be handled.

FWIW, my primary interest at this point is not precisely aligned with any of the above characterizations: I’d like to see a future in which validators (or conformance checkers) actually become useful once again.  And by that I mean (a) reflect what is in the specification, and (b) report only on things that are likely to cause problems.

If, for example, everybody agrees on how <b><i>foo</b></i> is to be rendered, then I see no purpose in flagging it.

For these people there is no inconsistency between including <i> in one place and excluding <input size=""> in another as long as a convincing justification can be made for the difference.

Is there one?  This list is awfully short.

I also think that there’s a much larger issue in the overall inefficiency of the HTML-WG; I am very worried we will never get as far as speccing useful new features because of the time spent on semantic navel gazing

What I would like to see is for that group to move away from general theory (and away from mis-characterizing each other’s motivations) to focus on specifics.

Like, for example, why exactly is the size attribute on the input element deprecated?  By seeing the explanation of specifics, we can all try to put the pieces of the puzzle together for ourselves.

Posted by Sam Ruby at

Don’t Break The Web

If, for example, everybody agrees on how <b><i>foo</b></i> is to be rendered, then I see no purpose in flagging it.

Good luck selling that goal to the working group :)

Actually, I think there is a good argument why this is a bad idea - although HTML5 browsers may all construct the same DOM tree in the case of misnested markup it is unlikely to be the one that the author of the code was expecting. If they later try to apply style or script to the DOM they will get unexpected results which, due to the lack of conformance checker errors, will be hard to isolate to a problem in the markup.

Is there one [reason for deprecating @size]?

Dunno. You could search the mailing list archives or ask Hixie. I think there may be problems with the units of @size being unspecified and, with CSS giving the same ability and a choice of units it does seem redundant feature (at least assuming @style is reinstated). However I’m not sure what the actual reasoning was.

Posted by jgraham at

Don’t Break The Web

ask Hixie.

done

Apparently, the answer is lost in the archives someplace; furthermore the prevalent opinion is that the purpose of the WHATWG (and presumably of the HTML WG) isn’t so much to document the web as she is practiced, but to actively make the web “better”.  Independent of common practice, such as google.com and ln.hixie.ch.

In my opinion, the only way to make the web better is to get browser vendors to agree to no longer implement a feature; simply documenting an attribute as deprecated or getting a conformance checker to flag it will have little effect.

Posted by Sam Ruby at

Don’t Break The Web

The spec will say how to render <input size=""> even if it’s considered non-conforming.

Will it?  It doesn’t now.

The web won’t get broken by removing some elements or attributes from the language spec as long as UAs retain support.

But the spec says, "User agents should support deprecated features."

[Sam, it seems the “Formatting Rules” on your comment preview page are no longer correct.]

Posted by Matt Brubeck at

Don’t Break The Web

Heh, disregard my last line ("But the spec says...").  I somehow read the spec’s SHOULD as SHOULD NOT.  And yet the text I copied and pasted actually agrees with jgraham.

Posted by Matt Brubeck at

Don’t Break The Web

“Don’t Break The Web” is not a rule you should obey, it is a guiding principle. I am much more interested in sites that really are broken — i.e. sites that no longer function. It seems that there are degrees of “broken”. I don’t really follow the HTML-WG list any more so I’m sure I’m missing something. If this is important then why not spell it out for the rest of us?

Posted by Dean Edwards at

Don’t Break The Web

I don’t really follow the HTML-WG list any more so I’m sure I’m missing something. If this is important then why not spell it out for the rest of us?

At the moment, the WG is dysfunctional.  People are spouting plattitudes and using them to pound each other.  Which is mildly amusing as many of the things they view as unacceptable when it comes from certain others, they view exactly parallel constructs as acceptable when it comes from different sources.

“Don’t break the web” is a classic example.  You can’t get rid of <i> because that would break the web.  How about width attributes?  That’s different, that’s <church_lady>presentational</church_lady> — unlike, um, <i> elements???!! — and that requires a use case.  How about Google as a use case?  Nah, that doesn’t count.  I guess it isn’t high enough profile.

Ultimately this will pass, and people will start talking about specifics.  That’s when people should start to pay attention again.

Posted by Sam Ruby at

Don’t Break the Web?

Sam Ruby: “Ultimately this will pass, and people will start talking about specifics. That’s when people should start to pay attention again.” Hmm.. Well, I’d already decided not to pay much attention until there was a concrete spec written and...

Excerpt from snellspace.com at

Don’t Break The Web

“Don’t break the Web” / “Support existing content” isn’t about making all existing content conforming. It is about making sure that UA conformance requirements do not require browsers do things that would break the pages.

I’d like to see a future in which validators (or conformance checkers) actually become useful once again.  And by that I mean (a) reflect what is in the specification, and (b) report only on things that are likely to cause problems.

If, for example, everybody agrees on how <b><i>foo</b></i> is to be rendered, then I see no purpose in flagging it.

I think consistent rendering in HTML5 UAs is not enough. On the tokenization and tree building levels, something should be an error if:

Now, document conformance on the higher level is harder to justify. For example, one could argue that bimorphic content models are a purely aesthetic requirement. I can see a practical reason for them, though. Writing a WYSIWYGish editor for HTML is harder if one is to support anything that browsers handle. Even though browsers have to handle non-conforming cases, be could accept that editors may mung original input into a conforming state. This way, editors would only need to come up with a UI for the conforming cases. Bimorphic content models would relieve such editors from supporting a mix of block and inline.

Posted by Henri Sivonen at

Don’t Break The Web

I think consistent rendering in HTML5 UAs is not enough. On the tokenization and tree building levels, something should be an error if

Good list, I’ll note that none of these conditions apply to most cases of <b><i>foo</b></i>.

Posted by Sam Ruby at

Don’t Break The Web

Sam, i and b do have use cases.  They’re for every other semantic use case of italics and bold in typography that aren’t covered by other, more specific  elements.  See my article about b and i.

The size attribute, however, doesn’t have much of a use case, except as a substitute for stylesheets.  There is nothing semantic about it.  Therefore, your argument that size should basically be included because b and i are, is flawed.

Regarding making validators useful by making them only emit errors when the error causes problems.  Well, since the spec will define how to handle any given input stream, technically nothing will cause a problem, and so you’d effectively be making a validator emit no errors whatsoever.  Great!  Looks like Henri can stop work, and just create a single static page that says: “Congratulations, your page is conforming HTML5!”.

Posted by Lachlan Hunt at

Don’t Break The Web

“Support existing content” doesn’t apply when it comes to keeping or dropping features from conformance (e.g. <input size>, <i>, <b>). It doesn’t matter if something is conforming or not for the purposes of authors, it doesn’t affect their existing content.

<input size> is on the chopping block because it has no reason to exist other than presentation. It’s a media-specific attribute.

On the other hand, <i> and <b>, as defined in HTML5, are media-independent. They handle use cases that would otherwise not be handled.

HTH.

Posted by Ian Hickson at

Don’t Break The Web

Looks like Henri can stop work, and just create a single static page that says: “Congratulations, your page is conforming HTML5!”.

This is a prime example of the dysfunctional operations of the working group.  Just a few hours before, and on this very post, Henri and I were talking about what makes sense for a validator to check for, and mostly agreeing.  In this very context Lachlan comes along and mis-characterizes exactly this topic and uses it to bash others (in this case me).

Posted by Sam Ruby at

Don’t Break The Web

This is a prime example of the dysfunctional operations of the working group.  Just a few hours before, and on this very post, Henri and I were talking about what makes sense for a validator to check for, and mostly agreeing.  In this very context Lachlan comes along and mis-characterizes exactly this topic and uses it to bash others (in this case me).

I would suggest that it would be useful for a validator to have settings for this.

A user might wish to inquire whether his document conforms to the Spec. On the other hand, he might wish to isolate a particular problem that is causing his document not to render as expected.

In the latter case, he may want to suppress errors that are unlikely to cause problems in an HTML5-compliant UA.

Lachlan’s comment (it seems to me) stems from anxiety over the question:

Aside from the issues you and Henri were discussing, why would anyone be interested in checking conformance of their documents?

Evidently, some people do value their ability to catch instances of non-conformance, even when such instance are (by design) unlikely ever to cause problems.

So, why not give them what they want?

Posted by Jacques Distler at

Don’t Break The Web

why not give them what they want?

Are you sure that what Ian wants is what you want?

Ian indicates that this attribute is on the chopping block because it is “presentational”.  My comment to this post was semantically correct, but the presentation was all wrong.  I see from your answer which one is more important to you.  I also note that the portion of MathML that of most interest to you is the presentational markup.

From all this, I conclude that what Ian wants (a spec that deprecates presentational markup) is quite different than what you might be interested in checking your content for conformance against.

Meanwhile, Lachlan indicated that he wouldn’t mind deprecating size as long as we get the style attribute.  Ian’s reply: size="" and style="" are both very media-specific.

Posted by Sam Ruby at

Don’t Break The Web

Are you sure that what Ian wants is what you want?

I have no idea.

I was responding to Lachlan’s comment (and your response to it).

My comment to this post was semantically correct, but the presentation was all wrong.

To nitpick, the presentation of your comment was just fine. It was the presentation of its (suggested) implementation in (presentational) MathML that would have been all wrong. Semantically, I don’t think there’s much difference between your suggestion and the solution I went for.

I also note that the portion of MathML that of most interest to you is the presentational markup.

There is far more semantics (potentially) present in “presentational” MathML than can be expressed in the chosen input language (TeX).

In fact, I do go out of my way, where possible, to choose the TeX input which will produce the more semantically-correct pMML output. I will, for instance, type

{(a+b)}^2

instead of

(a+b)^2

even though these produce visually-identical output (both in TeX and in pMML).

From all this, I conclude that what Ian wants (a spec that deprecates presentational markup) is quite different than what you might be interested in checking your content for conformance against.

Since the spec he wants will, in all likelihood, not include the ability to enter mathematical markup, I’m not sure it would make any sense for me to check my content for conformance against it.

Meanwhile, Lachlan indicated that he wouldn’t mind deprecating size as long as we get the style attribute.

I can see deprecating one attribute if, indeed, it is redundant with another. That way, one doesn’t need to specify which takes precedence when both are present and their values conflict.

But my understanding was that non-graphical browsers, like Lynx, honour the @size attribute, which says to me that

<input size="36">

and

<input style="width:36em">

are not quite equivalent.

Posted by Jacques Distler at

Don’t Break The Web

“Presentational” is not a meaningful term. Neither is “semantic”. Reality is a little messier. The HTML WG should give up the sophomoric art criticism, and the prescriptive nonsense that results. By focusing on the outcome of concrete examples, as it effects users, these digressions can be avoided.

So yeah, I agree with Sam. I am disappointed that WHAT-WG members, who are usually intensely practical, can be so easily swayed by Religion.

Posted by Robert Sayre at

Don’t Break The Web

Good list, I’ll note that none of these conditions apply to most cases of <b><i>foo</b></i>.

The typo and legacy considerations do apply.

No one has a legitimate reason to ever deliberately write <b><i>foo</b></i> in their non-test case markup. The misnested markup does not achieve anything useful that could not be expressed by properly nested markup. The misnested markup is certainly a typo and a conformance checker should, in my opinion, flag such obvious typos.

More importantly, even when the initial rendering of misnested markup makes sense in IE 7 or earlier, DOM manipulations of the resulting non-tree can cause exceedingly weird results. Since misnesting traditional elements provides no particular benefits but is potentially problematic in legacy UAs, I think it makes sense to flag misnesting as an error.

All in all, I think the error conditions in the parsing algorithm are good as they are. However, on the higher level, I’d like to get some “presentational” stuff like the align attribute on table cells and columns back.

From an aesthetic point of view and from the point of view of imagining myself in the shoes of a developer of a WYSIWYGish conforming-only editor, I rather like bimorphic content models. However, I am a tad nervous that the masses of authors will have a hard time accepting a change in the content model of div without any associated threat of breakage in browsers.

Posted by Henri Sivonen at

Don’t Break The Web

Since the spec he wants will, in all likelihood, not include the ability to enter mathematical markup, I’m not sure it would make any sense for me to check my content for conformance against it.

The spec has been drafted not to forbid markup from other vocabularies on the XHTML side. My long-term goals for XHTML5 conformance checking include allowing embedded SVG 1.1, MathML 2.0 and RDF by default (actually checking SVG and MathML and treating RDF as an anything-goes mystery tree).

As for the HTML5 side, I still think that extending the parsing algorithm to handle SVG and MathML is a worthy goal. We just need to figure out how to do it in a forward-compatible and relatively clean way.

Posted by Henri Sivonen at

Don’t Break The Web

The spec has been drafted not to forbid markup from other vocabularies on the XHTML side. My long-term goals for XHTML5 conformance checking include allowing embedded SVG 1.1, MathML 2.0 and RDF by default (actually checking SVG and MathML and treating RDF as an anything-goes mystery tree). As for the HTML5 side, I still think that extending the parsing algorithm to handle SVG and MathML is a worthy goal.

Well, maybe I should pay some attention then.

We just need to figure out how to do it in a forward-compatible and relatively clean way.

My, perhaps mistaken, impression of the upshot of the previous discussion of this in the WhatWG was:

If you wanna include other XML vocabularies (MathML, SVG), use the XHTML serialization.

I would imagine that the addition of Microsoft to the WG would not exactly strengthen the constituency for finding a way to allow these extensions in the HTML serialization.

But, perhaps, when the WG turns its attention from debating whether <i> should be deprecated to more serious matters, I will be pleasantly surprised.

Posted by Jacques Distler at

Don’t Break The Web

The spec has been drafted not to forbid markup from other vocabularies on the XHTML side. ... As for the HTML5 side, I still think that extending the parsing algorithm to handle SVG and MathML...

So what’s the difference? Why can other vocabularies be permitted in XHTML5 but not HTML5? Is the fact that they will actually work in HTML5 the reason? I don’t think such handwaving is sustainable.

Posted by Robert Sayre at

Don’t Break The Web

I lurk on many mailing lists following various technologies that affect the web, mostly I am dark matter and, as such, I have a slightly different perspective than most.

To my mind the most important part of the next version of HTML, the part that is most needed, the part that would help the greatest number of authors is forms. I’d argue that everything else is a red herring. My greatest fear, which appears to be bearing out from the initial months of looking over the shoulders of this working group is that forms will continue to be an afterthought - addressed only once people have fought their syntactic wars (religious and otherwise) and expended their energies on well... who knows. This would be just as in the early days of HTML which left us with our current predicament: a vast number of frameworks fighting browsers in order to wrangle simple form applications (and mostly failing), with things like XForms always 18 months away from deployment, with every vendor providing their own idiosyncratic take on form development. I don’t have much hair, but I’ll pull what hair I do have out if I’ll be saying wait another 18 months for good forms development 18 months from now. I was saying the same thing 18 months ago.

Dark matter is said to be the repository of much of the energy of the universe. I fear such energy will disappear and remain untapped. I know I don’t have the energy to delurk and dive in to these debates, the background noise overwhelms.

Observers are worried.

Posted by koranteng Ofosu-Amaah at

Don’t Break The Web

Gotta agree with Korateng – in thinking about it, what I miss most from HTML are better form controls. Just adding a few simple things like a slider, a date picker, and a control that allows a user to reorder a list would tremendously improve the experience of web apps. The absence of such controls can be worked around with Javascript, but that degrades badly, requires a lot of UA-sensitive code and has no good way conform to local UI conventions on users’ machines. CSS2 obsoleted tons of rollover scripts; likewise with a few extra form controls in HTML, half the Javascript that’s currently floating around the web could be deleted. Who knows, that might even significantly diminish the appeal of proprietary runtimes…

Posted by Aristotle Pagaltzis at

Don’t Break The Web

The spec has been drafted not to forbid markup from other vocabularies on the XHTML side. ... As for the HTML5 side, I still think that extending the parsing algorithm to handle SVG and MathML...

So what’s the difference?

The difference is that XML plus namespaces parsing supports SVG and MathML automatically. Traditional HTML parsing does not.

Why can other vocabularies be permitted in XHTML5 but not HTML5?

Because XML parsing doesn’t need to be extended to do so. HTML parsing would need to be extended. (Note that this is about parsing, not about adding stuff by DOM manipulation.)

Is the fact that they will actually work in HTML5 the reason?

No. SVG in text/html parsing does not work right now in SVG-enabled builds of Presto, Gecko or WebKit, AFAIK.

Posted by Henri Sivonen at

Don’t Break The Web

There is in fact a forms proposal for HTML5 which is already implemented in Opera and custom script libraries: Web Forms 2. So that is definitely not overlooked.

Posted by Anne van Kesteren at

Don’t Break The Web

The difference is that XML plus namespaces parsing supports SVG and MathML automatically.

Sure, in the parser.

HTML parsing would need to be extended.

Yes. Why is it preferable to consult a working group, at great expense, for every half-baked idea? The HTML5 spec extends parsing too, but not every parser will have to be extended in the same way.

No. SVG in text/html parsing does not work right now...

I meant that authors would be capable of producing it...

Posted by Robert Sayre at

Don’t Break The Web

Why is it preferable to consult a working group, at great expense, for every half-baked idea?

Six months ago, I created a patch.  To date, that hasn’t worked either.

My intent is to keep plodding forward.  Consulting with anybody who is willing to collaborate.

Fundamentally, I believe that the current state (where HTML is functionally a subset of XHTML, but operationally, HTML is more robust than XHTML) is unstable.

Posted by Sam Ruby at

Add your comment