Skip to content

Commit 405da68

Browse files
bert-githubbert-github
committed
spec/reviews/html5: Added my proposed comments
1 parent 468ec7d commit 405da68

1 file changed

Lines changed: 118 additions & 0 deletions

File tree

‎spec/reviews/html5.txt‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,3 +13,121 @@ This page is where the CSSWG will track our comments to the HTMLWG regarding the
1313
* case-insensitive attribute value matching; http://lists.w3.org/Archives/Public/www-style/2011Jul/0415.html
1414
* rendering depends on video { object-fit: contain; }
1515
* for defining <font> could be useful if CSS has font-size:xxx-large for a font size 50% larger than xx-large
16+
17+
==== Proposed comments by Bert ====
18+
19+
20+
=== Attribute value normalization is not backwards compatible ===
21+
22+
The way string-valued attributes are processed in HTML5 is not backwards
23+
compatible with the way in HTML4. In HTML4, newlines in the source
24+
become spaces in the attribute value, but in HTML5 they become line
25+
feeds and/or carriage returns.
26+
27+
This handling of line ends isn't specific to HTML, but is a property of SGML (and thus also XML) and thus it risks being difficult to change in existing software. In my own software, e.g., it is handled at a very low level in the tokenizer. And any software that works off a generic SGML or XML parser will not be able to get at the line breaks in the source.
28+
29+
It is also inconvenient: In HTML4, you can format the source code to
30+
avoid long lines:
31+
32+
... <span title="Some long title here">...</span> <span title="Some
33+
long title here">...</span>...
34+
35+
and the the two attributes will still be equal to one another, but not
36+
so in HTMl5.
37+
38+
=== Alternative style sheet handling undefined ===
39+
40+
HTML5 says that alternative style sheets are defined in CSSOM. There are
41+
two issues here. One is a question of timing: there is actually no
42+
version of CSSOM yet, not even a WD, that defines alternative style
43+
sheets. The other is a question of spec organization: why in CSSOM? It
44+
has nothing to do with the DOM, it's not where you would expect it, and
45+
why should an implementer need to learn to read the special language of
46+
the CSSOM spec just to implement alternative style sheets?
47+
48+
=== White space where HTML4 ignored it ===
49+
50+
In several places, HTML4 (or rather SGML) automatically ignores white
51+
space in the source, so that you can lay out the source more freely.
52+
E.g., this document has not a single white space character:
53+
54+
<!doctype html public '-//W3C//DTD HTML 4.01//EN'>
55+
<html>
56+
<head>
57+
<title>Test</title>
58+
59+
<body>
60+
61+
<table>
62+
<tr>
63+
<td>one</td>
64+
<td>two</td>
65+
</table>
66+
67+
HTML5, on the other hand, sees lots of spaces and line feeds in this
68+
document. People will want to lay out the document like this anyway, and
69+
the result is that the white space will have to be removed at some other
70+
stage in the processing.
71+
72+
In anticipation of HTML5, CSS already added some rules to ignore spaces
73+
that are likely to be not significant, but as CSS has no access to the
74+
mark-up, those rules are necessarily wrong in some cases.
75+
76+
If the document is processed by some other system than CSS, that system,
77+
too, will need to deal with white space that may not have been
78+
significant.
79+
80+
It would be better if HTML5 remained backwards compatible with HTML4 in this case, ignoring non-significant white space in all places where HTML4 ignores it, too.
81+
82+
=== Collapsing/expanding text and the DETAILS element ===
83+
84+
The DETAILS element (finally!) introduces the traditional hypertext feature of expanding text ("stretch text") into HTML. However, there are two problems.
85+
86+
Current CSS cannot express the desired behavior of the DETAILS element. Although there have been proposals in the past, none have yet been published by the CSS WG and the HTML WG hasn't asked the CSS WG for this feature either. Putting DETAILS in a last-call document when the corresponding CSS isn't even a WD yet seems a bit of a timing problem at least.
87+
88+
Moreover, all the (informal) proposals in CSS so far have dealt with collapsing elements where the parts to show and the parts to hide were elements or attributes (e.g., LI elements in a collapsible list, or TITLE attributes). Maybe it is possible to invent pseudo-elements for the collapsible content of the DETAILS element, but it is probably better to add an element, e.g.: <DETAILS><SUMMARY>...</SUMMARY><BODY>...</BODY></DETAILS>. At least the choice of mark-up needs further investigation and should be coordinated with the CSS WG.
89+
90+
=== Automatic height for transcluded elements (SEAMLESS attribute) ===
91+
92+
Another timing/coordination problem is the SEAMLESS attribute. CSS currently says that "replaced elements" (CSS's term that loosely corresponds to transclusions) that don't have an "intrinsic size" will be 150px high. An HTML document, e.g., doesn't have an "intrinsic size" under the definition of current CSS, and thus <IFRAME SEAMLESS...> will be 150px high, with or without SEAMLESS.
93+
94+
There are ideas to extend CSS and allow resources that do not have a fixed aspect ratio, but that do nevertheless have a definite height for each given width (such as HTML documents) to be rendered with that height, instead of 150px. But those ideas aren't yet at a state where HTML can take them for granted.
95+
96+
It's a nice feature: "seamless" transclusion is obviously more attractive than transclusion in a 150px-high box with a scroll bar, but it urgently needs coordination with CSS.
97+
98+
=== Scoped style sheets ===
99+
100+
Scoped style sheets are complex, difficult to maintain for authors, and not needed. Especially with the SEAMLESS attribute, there is no need to combine separate documents in a single file, they can be transcluded instead. That keeps each of them simple, easy to maintain, easy to re-use, and easy to parse: one head with one style, one body, and its own URL.
101+
102+
If it is necessary, e.g., for transport reasons, to combine several resources in one file, it is better to use a generic solution, that works not only for HTML documents, but for any documents. That could be, e.g., a zip or tar file or a multipart MIME file.
103+
104+
=== Chapter 10 more clearly marked as informative ===
105+
106+
Chapter 10 says that it is not normative, but it says it in a rather roundabout way. It would probably avoid confusion if it actually had the literal words "informative" or "not normative" at the top.
107+
108+
=== Case-insensitive XML ===
109+
110+
Chapter 10 on rendering seems to say that elements and attributes are matched against CSS selectors in a case-insensitive way, even if the document is in XML. (The chapter itself is not normative, but I assume it says that because there is corresponding normative text somewhere else.) That contradicts XML. It also breaks existing style sheets, e.g., user style sheets that rely on the fact that
111+
112+
body [color: green}
113+
BODY {color: blue}
114+
115+
makes XHTML documents green and HTML ones blue.
116+
117+
=== Pseudo-namespaces in HTML ===
118+
119+
That same chapter 10 also seems to say that
120+
121+
@namespace url(http://www.w3.org/1999/xhtml);
122+
sup { vertical-align: super; }
123+
124+
applies to HTML as well as XHTML. Currently, HTML documents don't have a namespace (after all, they are not XML), and so it is easy to distinguish HTML from XHTML in CSS by omitting the namespace:
125+
126+
h1 {...} /* HTML and XHTML */
127+
x|h1 {...} /* XHTML only (after suitable defn of "x") */
128+
|h1 {...} /* HTML only */
129+
130+
If HTML5 is not backwards compatible with HTML4 in this respect, many existing style sheets will break (unless the UA is able to distinguish HTML4 from HTML5).
131+
132+
133+

0 commit comments

Comments
 (0)