Re: [whatwg] Validation
!DOCTYPE html6 would be an abomination, unless the root element changes to html6 also :-)
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
The specification says: For historical reasons, if the URL is a javascript: URL, then the user agent must not, despite the requirements in the definition of the fetching algorithm, actually execute the given script; instead the user agent must act as if it had received an empty HTTP 400 response. [4.3.1] (This is probably needed because the script block type overrides the script type, which is, in this case, text/html.) While we are at it: 1. What is the script source of inline scri...@type='text/xml']? The rules are contradictory: source = text because it is text-based and source = infoset because it is XML-based. (An external script is created with the source text without any preliminary parsing.) Does being XML override being text? 2. Why is the special provision for XML needed at all? Does it require invoking an embedded XML parser before the script is created? Does it allow nested script elements? (That would not be backwards-compatible and it would be fatal for HTML error recovery.) What if the XML is not well-formed? Is the embedded parser allowed to validate the XML? What if validation fails? Are external DTD allowed? --- forbidden? Are XHTML scripts embedded in the XML code allowed to run in this step? (they should not be!) 3. Why is the script source for XML-based scripts allowed to be a node list? Internet Explorer supports only well-formed XML documents, i.e. single trees, otherwise you get a parse error which is not very useful, except for the developer. 4. Is scri...@type='text/xml'] allowed to be externally loaded? (I suppose that it is allowed, if supported by the browser, in spite of the specification requiring data scripts to be inline.) 5. Is the browser allowed to expose the embedded XML document using a custom DOM property like XMLDocument? Creating an XML script means attaching the infoset to the declaring script element in Internet Explorer. I think most of these questions would be void (postponed to the creation phase where the answers are implementation-defined) if the special definition of source for inline XML script blocks was removed. Thx in advance, Chris
Re: [whatwg] Validation
The comparison to Don Quixote is skew; HTML (hopefully) improves while spoken languages (just as currencies) deteriorate. Chris -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Eduard Pascual Sent: Monday, July 20, 2009 11:12 PM To: dar...@chaosreigns.com Cc: whatwg Subject: Re: [whatwg] Validation Of course, a lot of legacy content will no longer validate with HTML5 validators; but where is the issue? It will still render. After all, no one would expect Don Quixote or Hamlet to be valid according to modern Spanish and English rules, respectivelly, but people who know either language are still able to read them. This is an inherent part of language evolution; and hence is a needed side-effect for evolving HTML. And we need to evolve HTML, becuase the current standard is over a decade old, and is falling short to the web's needs every now and then. Just my PoV anyway. Regards, Eduard Pascual
Re: [whatwg] Chipset support is a good argument
As the Eolas or RIM cases show, patent trolls can wait for a very long time until they are sure that their victim has no way out. It does not prove that Theora is clean that Google has not been sued yet. IMHO, Chris
Re: [whatwg] HTML5 competing with XML
A clean way to insert extraneous elements into SGML is to use NOTATION entities. This does not work for HTML and it has never worked, although TBL did have such an idea for images at the very beginning. It cannot be done because it is extremely inconvenient for the author/publisher and very insecure on the WWW. Otherwise, you can think of MATH and SVG in HTML5 as an analogue of SCRIPT, which is of course very weak - but you cannot verify the validity of JavaScript code with a DTD either. And you can have a DTD for XHTML5 with MathML and SVG using XML modularization (although the WHATWG does not provide you with one). The DTD in question would of course be an upper approximation of what is allowed. HTH, Chris
Re: [whatwg] Chipset support is a good argument
Small authors are hardly an alternative to YouTube because they use YouTube (or a similar service) to publish their content. Neither do YouTube publish most of the stuff on their own; they only allow the authors to do it using YT technology. In short, if you do not have the know-how to serve your video content, you will just use YouTube and never bother. And if you do have, you will not begin with reading the HTML specification either. IMHO, Chris
Re: [whatwg] DOMTokenList feedback
Regarding DOMTokenList, why not: contains(): true add,remove,toggle(): no effect? Are there situations that would require an exception to be thrown, or else the page would go out in a blast? Chris
Re: [whatwg] Chipset support is a good argument
For those of you that are concerned whether Microsoft will support web video: Internet Explorer already does, albeit in the Microsoft WayT: * dynsrc Property (IMG, INPUT, INPUT type=image, ...) URL:http://msdn.microsoft.com/en-us/library/ms533742(VS.85).aspx :-)
Re: [whatwg] In AppCache web apps, images from unpredictable domains won't load
Not loading cross-domain images in e-mail messages is a standard privacy feature e.g. in Microsoft Outlook. (Indeed, that means that Microsoft Outlook does not allow any external images, only attachments). The workaround, to save as a HTML document and view in browser, should work. If the images are important and viewing them stand-alone makes sense, the user can also use the URL from image properties. Therefore I do not think this particular problem is worth fighting with for off-line Web applications. IMHO, Chris
Re: [whatwg] Codecs for audio and video
Audible mouse feedback is an OS thing, not an HTML thing. I would rather have programmatic access to the MIDI synthesizer rather than be able to simulate it with a beep. How do you detect that the client mixer is too slow? Why can't you just get the premixed jingles from the server? Isn't the reading voice a CSS thing? Isn't sound transformation hard enough to deserve a complete API? I think allowing playing with binary audio data is not going to help most programmers who do not have the slightest idea of how to deal with it. Imagine a Canvas interface with PutPixel only. IMHO, Chris
Re: [whatwg] do not encourage use of small element for legal text
I have addressed all Andrew's points previously. Please forgive my posting an outline of the arguments here. 1. The specification does not encourage using the SMALL element for legal notices. It merely allows the SMALL element to contain legal notices. 2. Legal texts are unreadable on their own; putting them in small text does not make them any less readable. This statement does not make me an anarchist; I can say the same about math :-) 3. Legal texts are best read copied to Notepad because they do not and cannot contain any normative markup. (They are also best displayed in an inline frame, especially because the editor of the page is usually not allowed to edit them.) 4. I concur that warranties should be added to disclaimers in the text to make it less negatively biased. IMHO, Chris
Re: [whatwg] Codecs for audio and video
Regarding the fear of Trojan codecs: it would help if third-party plug-ins for codecs could be sandboxed so that they cannot have access to anything they do not have to access in order to do their job, and only via an API provided by the host. IMHO, Chris
Re: [whatwg] Codecs for audio and video
Clearly allowing a third-party codec to reprogram a hardware DSP would be one of the silliest things to do. (If it turns out that I cannot answer to something important from now on, assume I am banned for using an offensive word.) Chris
Re: [whatwg] the cite element
The CITE tag does not mean I am a citation. It is as confusing for novices as can be but the specification cannot do anything about it because it is already established. It means Citing what? and it does not mean Citing whom?. A book title is the obvious answer to this question. As I understand it, the CITE element can contain an anchor around the title, so you can have a URI as well. In particular, it could be an ISBN URN, although the browsers would have to support the ISBN namespace instead of saying Bad URL or something. HTH, Chris
Re: [whatwg] the cite element
If more then titles means other uses of the CITE tag, as evidenced in [1], they do not form any pattern. They look more like random errors. If more then titles means title and something else, I do not see much harm in such syntax. Chris [1] http://philip.html5.org/data/cite.txt.
Re: [whatwg] Codecs for audio and video
Even if Apple decides to implement Ogg Theora, iPod users will still get QuickTime served and get a better rendering because the common codec is the failsafe solution and will be specified as the last one. This phenomenon is expected to happen for any platform, not just Apple's. I cannot see how this effect can be perceived as diminishing the significance of the HTML specification, however. I believe proprietary codecs will always be better than public domain codecs, until hardware development makes this question irrelevant, because this application requires a large investment in research. I understand that the reason for rejecting MPEG-1 as a fallback mechanism is that the servers will not serve it because of increased bandwidth usage, right? Cheers, Chris
Re: [whatwg] Codecs for audio and video
Assuming bandwidth will increase with technological advance, it seems unreasonable that the bandwidth issue is allowed to block fallback solutions such as PCM within a specification that is expected to live longer than three years from now. IMHO, Chris
Re: [whatwg] Issues with Web Sockets API
Cellular phone signal strength bars are not implemented on top of Web Sockets so this cannot make a use case. This is rather a hardware thing. On the other hand, I concur that a network queue overflow should be handled differently than an out-of-memory condition. For example, if you have an infinite enumerator sending data to memory à la chargen service, an overflow failure is guaranteed and the programmer will have to do something about it; on the other hand, if the same enumerator sends data to a network, the failure will be random, depending on enumerator speed, network throughput and receiver capabilities. I think that the output buffer should not grow unbounded and the sending worker should be stopped while the buffer is full. Cheers, Chris
Re: [whatwg] Issues with Web Sockets API
Given the evident complexity of the Web Sockets protocol with respect to acknowledgements, events and updating host state for the script, is there a modelling diagram to view? Chris
Re: [whatwg] [html5] r3316 - [e] (0) A quick introduction to HTML.
Attributes are placed inside the start tag, and consist of a name and a value, separated by an = character. The attribute value can be left unquoted if it is a keyword [*or a number*]. IMHO, Chris
Re: [whatwg] New work on fonts at W3C
A server serving documents containing references to content from other sites, embedded or not, does not distribute that content. It would only redistribute in case of hot piping. Some sites have a policy disallowing publishing backdoor hyperlinks; the legal implications of such a policy are questionable (it is a collision with the free speech principle), but it can be applied if considered valid and enforceable. Limiting browser access to cross-site resources does not prevent copyright violation, at least not for images, because the publisher can use a (possibly illegal) mirror; a Flash applet can figure out it is being served from somewhere else and refuse to run but static content will display all right. The right answer to this problem, if it is really a problem, is to embed licensing information into the resources themselves, as in EOT fonts. IMHO, Chris
Re: [whatwg] New work on fonts at W3C
If browsers start refusing cross-domain image requests, some servers will work around this problem using hot piping. I am not sure this would be good-but I cannot say it would be bad either. IMHO, Chris
Re: [whatwg] External document subset support
You can easily include a cross-domain script using a cross-domain DTD; just
attach the malware as
!ATTLIST body onload CDATA { sniper.shoot(); }
and hope for the worst.
Chris
Re: [whatwg] Dom as Audience Prereq
Unlike in previous versions, the DOM is the skeleton and the underlying model of the specification. Even if there are sections that do not reference the DOM explicitly, a reader that tries to apply them to anything will not probably be able to draw the right conclusions without a basic knowledge of the DOM. IMHO, Chris
Re: [whatwg] b Lede Example
A lede is a summary or an invitation to read the whole article. It is semantically relevant; the reader may ask, e.g., Give me the ledes and I shall choose what I would like to read. Asking for the first paragraph of each article is not that practical, as the article need not contain a lede there, in which case it is better to return nothing. IMHO, Chris
Re: [whatwg] HTML 5 video tag questions
The first video source that can be played wins. You cannot provide alternative versions for different languages or resolutions in one VIDEO element. Chris
Re: [whatwg] HTML 5 video tag questions
Media queries can be done the same way as for images. Similarly, the server can choose to serve a localized version of any resource whatsoever. These customizations should not be put into VIDEO because their scope is wider. IMHO, Chris
Re: [whatwg] Browser Bundled Javascript Repository
The common JavaScript libraries should be identified using urn scheme with JavaScript namespace, as in script src=urn:JavaScript:cool-acme-lib:1.0 /script Chris
Re: [whatwg] Browser Bundled Javascript Repository
URI are expected to be readable. If we admit that many HTTP URL aren't readable and there is little we can do about that, maybe we could stretch the URN a bit to allow a hash in it? Chris
Re: [whatwg] Definitions of DOMTokenList algorithms andelement.classList
I would consider it a big advantage to the posterity if the descriptions and
the algorithms were better formulated and ready to be understood in plain
text. For example, regarding 2.8.3 DOMTokenList, (see appendix).
LEGEND
Code samples are in braces; my comments are in brackets, and so are
important [*changes*], [-deletions-] and [+insertions+]. I understand this
effect cannot be automatically provided by the HTML view.
SUMMARY
Generic changes:
Find index; Replace position;
Find token argument; Replace given token;
[this is not strictly necessary, any uniformity would do]
Insert the where appropriate.
Specific changes: see below.
Cheers,
Chris
Appendix:
* { tokenCount = tokenList . length }
--- Returns the number of tokens in the string.
{ [*token*] = tokenList . item([*position*]) }
{ [+token =+] tokenList[[*position*]] }
--- Returns the token [*at the position given*]. The tokens are sorted
alphabetically.
[I would not say that a token has an index; an index is not a property of
the token.]
Returns null if [*the position*] is out of range.
{ hasToken = tokenList . has(token) }
Returns true if the token is present; false otherwise.
[
It may be slightly misleading to speak of tokens _in parameters_. The
present description means that the corresponding LISP binding would be
{ (let ((has-token (ask token-list 'has 'token }
Rather than
{ (let ((has-token (ask token-list 'has token }
Of course, I may be entirely wrong here in that the first snippet is what is
intended.
]
Throws an { INVALID_CHARACTER_ERR } exception if [+the+] token contains any
spaces.
[In which case it is not a token at all, so this remark makes no sense.]
{ tokenlist . add(token) }
[*Inserts*] [+the+] token [+into the list+], unless it is already present.
[Inserts because the list implementation is sorted.]
Throws an { INVALID_CHARACTER_ERR } exception if [+the+] token contains any
spaces. [?]
{ tokenList . remove(token) }
Removes [+the+] token if it is present.
Throws an { INVALID_CHARACTER_ERR } exception if [+the+] token contains any
spaces. [?]
{ hasToken = tokenList . toggle(token) }
Adds [+the+] token if it is not present, or removes it if it is.
[Returns what?]
Throws an { INVALID_CHARACTER_ERR } exception if token contains any spaces.
[?]
The { length } attribute must return the number of unique tokens that result
from splitting the underlying string on spaces. This is the length. [Why
this Biblical tone?]
The [*positions of the supported enumerated tokens within the list*] are the
numbers in the range [+from+] zero to length[*minus;*]1, unless the length
is zero, in which case there are no supported [*enumerated*] properties.
The { item([*position*]) } method must split the underlying string on
spaces, sort the resulting list of tokens by Unicode code point, remove
exact duplicates, and then return the [-indexth-] item in this list [+at the
given position+]. If [*the position*] is equal to the number of tokens or
greater, then the method must return null.
The { has(token) } method must run the following algorithm:
1. If the [+given+] token [-argument-] contains any space characters, then
raise an { INVALID_CHARACTER_ERR } exception and stop the algorithm.
2. Otherwise, split the underlying string on spaces to get the list of
tokens in the object's underlying string.
3. If the [+given+] token [-indicated by token-] is one of the tokens in
the object's underlying string then return true and stop this algorithm.
4. Otherwise, return false.
The { add(token) } method must run the following algorithm:
1. If the [+given+] token [-argument-] contains any space characters, then
raise an { INVALID_CHARACTER_ERR } exception and stop the algorithm.
2. Otherwise, split the underlying string on spaces to get the list of
tokens in the object's underlying string.
3. If the given token is already one of the tokens in the { DOMTokenList }
object's underlying string then stop the algorithm.
4. Otherwise, if the { DOMTokenList } object's underlying string is not the
empty string and the last character of that string is not a space character,
then append a U+0020 SPACE character to the end of that string.
5. Append the [*characters*] of [+the+] token to the end of the {
DOMTokenList } object's underlying string.
The { remove(token) } method must run the following algorithm:
1. If the [+given+] token [-argument-] contains any space characters, then
raise an { INVALID_CHARACTER_ERR } exception and stop the algorithm.
2. Otherwise, remove the given token from the underlying string.
[
You leave two consecutive spaces here.
Why do you insist on not allowing an initial space above? ]
The { toggle(token)} method must run the following algorithm:
[This algorithm is redundant because it is a secondary method that can be
implemented in terms of {has}, {add} and {remove}. ]
Objects implementing the DOMTokenList interface must stringify to the
object's underlying string representation.
Re: [whatwg] nostyle consideration
How would you hide the NOSTYLE element for legacy browsers that support STYLE? What about browsers that support an alternative style type and not CSS? (This is academic, I know, but here you have NOSTYLE where you really mean NOCSS :-() Chris
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
Uniqueness of tokens can be determined in O(n) only* if the tokens are ordered in the source (any order would do) but there is no such requirement, and it cannot be required for compatibility with the content in the wild and because the standard supports inserting new tokens. It is possible to ignore this issue and proceed as if the tokens were ordered. The result would be that remove would fail, or it would run in quadratic time. HTH, Chris * If all possible tokens are predefined and their number is finite and the source is valid, uniqueness can be determined in constant time. This scenario, however, is better served by a bit field than by a token list.
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
The complexity of using a set/map is logarithmic in the size of the set. Multiply by the number of steps, you get what it takes. Chris
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
The complexity of using a set implemented as hash table is quadratic in the number of elements because of hash collisions. Chris
Re: [whatwg] Vulgar fractions
Actually aligning vulgar fractions is not even a CSS thing, it is an OpenType thing. Chris
Re: [whatwg] Proposal: JavaScript stack traces
The ability to extract stack trace information from an exception is a script language feature; it has nothing to do with HTML. Chris
Re: [whatwg] ODF and RDFa (was: Re: on microdata in html5)
While we are at RDF, I would like to complain that the concept Rendered content goes into metadata is good for English, Chinese and Bulgarian but it is inappropriate for inflected languages like Polish or Finnish (Finnish is also agglutinative, to make matters worse). Any decision along these lines is going to make life hard for users of inflected languages. For example, wikilink magic is commonly used on the English Wikipedia and almost useless on the Polish Wikipedia. IMHO, Chris
Re: [whatwg] Expose event.dataTransfer.files accessor to allow filedrag and drop
Microsoft has recently invented and deployed a custom ActiveX component to drop local files onto Live Spaces. This component is undocumented and it is probably limited to the Spaces service. Chris
Re: [whatwg] Helping people seaching for content filtered by license
A JavaScript-based viewer for images can overlay an image within an IFRAME and the IFRAME may contain the license link. HTH, Chris
Re: [whatwg] Annotating structured data that HTML has no semanticsfor
* Let a COLOR element have a value DOM property in the DOM that returns a color. * Let a NUMBER element has a value DOM property that returns a number. Actually, the latter use case is one I have bumped into: * The DOM does not provide a numeric value, * JavaScript support for parsing localized properties is poor; you have to reverse engineer the result of toLocaleString, * VBScript support is better but inconsistent as it depends on the system locale and not on the document locale as desired. IMHO, Chris
Re: [whatwg] Annotating structured data that HTML has no semantics for
The problem of W3C DTD DDoS does not apply to CURIE because software processing RDF does not need to retrieve the resources referenced on a regular basis. Even in the case of DTD, the problem is that some software does not cache, not that some software tries to access it. IMHO, Chris
Re: [whatwg] the cite element
Regarding your example: cite class=bibliography-item Smith, John. iThe Triumph of HTML 5/i. 2015. New York: Faraway Press. /cite I think we can agree that one could use such a syntax outside of running text, as in appendices, footnotes and the like. There is no much harm even if the whole entry is italicized, because it will be clearly stand-alone. Moreover, no validator is going to catch you on that, at least not in the near future. In the far future, on the other hand, the browsers will be able to infer the meaning from the text and semantic markup like that will be unnecessary. I think this part of the standard should be taken with some flexibility. It is fine to make little extensions for unanticipated contexts. And besides, regarding the problem with untitled works: In his untitled work CITE /CITE . Will do. IMHO, Chris
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
People are reluctant to learn new tools and new ways. Most of the time it is a sane protection from overwhelming abundance. It is not limited to programming languages, it can affect also video encoders. It even affects telephones (some people dislike telephones with keys). Bjarne Stroustrup on this (quoting from memory): I used to expect the programming languages of the future would be as easy to use as a telephone. Now I do not know how to use my telephone any more. Moreover, I suppose every video encoder has parameters that you adjust to get the best results, depending on the source video, so the problem is not limited to choosing another encoder. IMHO, Chris
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
The VIDEO element will not be useless without a common decoder. Its usefulness depends on its content: it will be limited to user agents that support at least one encoding offered by the author. Even if a common decoder is specified, many authors will not use it because they do not know it, they do not have the tools, they are reluctant to learn or they consider the proprietary solution better for production and valid for their target audience. IMHO, Chris
Re: [whatwg] the cite element
Instead of: liqMan is the only animal that laughs and weeps./qbr / -- citeWilliam Hazlitt/cite/li Consider: liqMan is the only animal that laughs and weeps./qbr / (William Hazlitt)/li Reads equally good, if not better. Bibliographic references are a topic of its own, and it is not going to be solved with the CITE element alone. Bibliography is a form of a database while hTml is mostly about text. The best HTML approximation to a list of bibliographical references is a table, except that tables tend to be unreadable when they are too wide. You could also use A HREF=urn:ISBN:. CITE A brief history of time/CITE /A and let the UA figure out the details. Removing the default style from CITE is too fragile: using the style attribute makes the code messy and using a class will not survive copy-paste. Chris
Re: [whatwg] Vulgar fractions
Vulgar fractions should be supported in hypertext markup without recourse to MathML. They are vulgar, after all. Requiring the full-blown math rendering engine for everyday business activities, cooking and the like is hardly acceptable for authors that use vulgar fractions for quantities and prices (the latter perhaps historical) but do not understand much in mathematics (it is quite possible). (OTOH, I sort of suspect that this rendering mechanism can be delegated to CSS because it is a general typesetting mechanism not specific to HTML.) IMHO, Chris
Re: [whatwg] Vulgar fractions
I think it is perfectly reasonable to expect authors to enter their markup in a TEXTAREA box with no bells and whistles. I am not against MathML math (of course) but requiring MathML for cooking recipes is wrong. Chris
Re: [whatwg] Pre-Last Call Comments
Small-print legalese is dull, repetitive, has little to do with the actual content, requires a trained lawyer to read and usually contains almost no markup. Sites often wrap it in a scrollable box so that it does not interfere with the page. Even if the target reader manages to read that stuff, there is little chance that she will understand it correctly. The way to deal with small print is to copy it out of the page as text and send it to your lawyer for interpretation. The recommendation of keeping small print small should be kept. If the reader happens to have a chance to understand it herself, she can restyle it in user CSS or use the zoom tool on it. IMHO, Chris
Re: [whatwg] the cite element
The level of surprise of an article cited as a book is far smaller than a real author looking like a fictitious person, as in the default rendering of CITE Aristotle/CITE said. Not everybody is an expert in scholarly style guides but most readers feel the difference between direct speech and indirect speech. You can, of course, say It was not EM Plato/EM , it was EM Aristotle/EM ! but this kind of emphasis is rarely needed and the interpretation of the rendering is obvious from the context in this case. I contend that citing articles from periodicals is not well supported, starting with the problem of lack of support in the NID urn:ISSN. However, formal citations are not inserted into running text, which is what the CITE element in principle is for. They are set aside as footnotes or endnotes in order to keep the text readable. There is nothing wrong with the default rendering of the article title in running text where symbolic bibliography references are not used, e.g. because the text is for the average reader. IMHO, Chris
Re: [whatwg] [html5] Pre-Last Call Comments
The ActiveX components I use are proprietary non-standard technology. Granted. However, the interface to them, HTML, is standard and non-proprietary. Of course, one can use proprietary extensions like namespaces and data sources as well, and sometimes it is necessary for rendering and data management, but the classid attribute has not been the case until (yesterday). Valid code simply makes a better interface overall, which means validating it makes sense. Using IE magic comments causes the validator to skip not only the parts that have been invalidated, such as the classid attribute, but also the parts that would be valid otherwise. If there is error in there, it will go undetected, which is bad. Chris
Re: [whatwg] the cite element
Rendering the name Aristotle in italic by itself, if not used for emphasis, indicates that the name is used in an oblique, indirect way, perhaps referring to a fictitious person or a nickname, the person referred to as Aristotle by a 3rd party. Please do not ask me why this is so; I shall not be able to give a definitive answer. You may disagree, of course. I never said that titles MUST be rendered in an italic style. All I said is that, in the context where scholarly style guides prescribe normal style, the surprise factor of the user agent rendering it in italic style instead is negligible. OTOH, the surprise factor of the user agent rendering the *author* in italic style is unacceptable. I fully agree that this is an unfortunate circumstance. IMHO, Chris
Re: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate.
The HTML element cannot have a FIELDSET element as a child. It can, however, have a FRAMESET element as a child. Chris
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
The definition of uppercasing in HTML does not apply to element names because getting them is covered by the DOM specification and not by the HTML specification. This is all right with me; I only think that saying to uppercase ASCII explicitly is not necessary. Chris
Re: [whatwg] [html5] Pre-Last Call Comments
The validator generates an error for the classid attribute (in line with what the specification says, I think). An error, unlike a warning, breaks any complex process that depends on successful validation of the components. I think the specification text should be rephrased so that the validator can issue a warning instead. For the time being, the only practical workaround for this incompatibility is to use Internet Explorer magic comments. IMHO, Chris
Re: [whatwg] [html5] Pre-Last Call Comments
Regarding http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure. html#weeks: A week begins on Sunday, not on Monday. However, under the present assumption: Better: A week-year has 53 weeks if the first day of the year (January 1st) in the proleptic Gregorian calendar is Thursday or the year is leap and the first day of the year (January 1st) in the proleptic Gregorian calendar is Wednesday. All other week-years have 52 weeks. Better still: A week-year has 53 weeks if February the 28th in the proleptic Gregorian calendar is Saturday or February the 29th in the proleptic Gregorian calendar is Saturday. All other week-years have 52 weeks. Also note, x-x-big5 cannot be registered with IANA because it is already registered for private use. HTH, Chris
Re: [whatwg] Workers and URL origin check
I was wrong: CONST values and conditional compilation variables land as properties of the window, which means they are unavailable to other scripts only if the defining script is external and deferred. Still, I do not think this behavior is mandatory for run-time; there may be symbols that are handled by the parser and do not survive after the script has been loaded. Admittedly, neither JavaScript nor Basic support such a construct, but it would be easy to think of a scripting language that does. Hypothetically, Chris
Re: [whatwg] Workers and URL origin check
Inserting a SCRIPT element is not equivalent to a server-side include. It is more like linking to an object file. In particular, substitution macros (e.g. CONST in BASIC) in one script do not apply other scripts (all scripts present have already been parsed, and applying them to future scripts would be to fragile). Does it also apply to importScripts? Chris
Re: [whatwg] External document subset support
The localization of your site starts with connection negotiation where the representation of resources served depends on the browser's language of choice. Configuring the server to support this needs some technical expertise, and so does using a server-side scripting language. External DTD support is not required for entities; they may be repeated in the internal subset for Safari. This repetition is only a minor nuisance to the editor because only the entities that the text actually includes are needed, which usually amounts to a few entities for symbols (right arrow family) and typographic marks (non-breaking space family). (I am talking about standard entities here, not entities for customization that are likely to change; such use should be discouraged). If everything else fails, the internal subset may be provided as a server-side include. IMHO, Chris
Re: [whatwg] page refresh and resubmitting POST state
I certainly want refresh to redo, for example, when validating a local document that I am editing. Chris
Re: [whatwg] page refresh and resubmitting POST state
If the local document is being edited in Notepad and bound to the validator via a file input control, refreshing the page should resubmit the file. Chris
Re: [whatwg] on bibtex-in-html5
If markup for a publication identifier in a reference is required, can this identifier be an URN-encoded? The NID will tell what kind of an identifier it is. I have used q cite=urn:ISBN:whatever myself, perhaps not quite in line with the definition of the Q element but, since the cite attribute in XHTML is not universal (as it is in XHTML2), I have not been able to find a better container element to attach an URN to it. IMHO, Chris
Re: [whatwg] External document subset support
AFAIK, WebKit is not going to validate XML, they say it makes page load too slow. Besides, entities introduce a security risk because it can contain incomplete syntax fragments and they can open a path to XML injection into, say, ![DANGER[span title=malicious-entity; sweet kittens/span ]]. So XML processors often refuse to load cross-domain DTD or ENTITIES. There are several XHTML entities that are indispensable for authors, namely those that disambiguate characters are invisible or are indistinguishable from others in a monospaced typeface. These include spacing, dashes, quotes and maybe text direction (deprecated). Converting them to their corresponding characters deteriorates the editing experience in an ordinary text editor. As far as codes for letters are concerned, text in a non-Latin script would consist mainly of entities, which would make it extremely hard to read, so this approach is not practical. An editor limited to the ASCII character set would be better off using a transliteration scheme and a converter. However, as some of the entities are indispensable, a DOCTYPE is required. The browsers may support built-in entities but XML processors used to process XHTML documents need not. Providing a set of the entities needed in-line is easy; however, the problem is that some validating processors like MSXML require that the DTD, if provided, should fully describe the document; providing entities only is not supported by default and the processor refuses to load the document. That means a DOCTYPE for XHTML is necessary and should be provided by WHATWG (or by an independent party). This DTD should be external in order to use parameter entities and, of course, to make the document smaller. It cannot, of course, define all nuances of XHTML, but an upper approximation would be sufficient. The problem, of course, is maintenance, since XHTML is in flux. XHTML is currently described formally by a RELAX NG grammar and maintaining a separate DTD would double the work to do so it would be best to be able to generate the DTD automatically. However, the converter I was advised to use was unable to produce a DTD from the grammar because it is too complex for the DTD formalism (of course). Best regards, Chris Aside: Note that you cannot use DocBook with MSIE directly; a bug in the default XSLT processor causes an error in initialization code. This kills all transformations, whatever your document is. (I do not know about TEI.)
Re: [whatwg] Annotating structured data that HTML has no semanticsfor
Being unable to deal with all use cases sometimes is a feature. For example, regular expressions are unable to recognize all recursive languages; it is a feature. As a compensation for that loss, they do not suffer from the halting problem. HTH, Chris
Re: [whatwg] External document subset support
Using entities in XSL to share code was my mistake once too; it is similar to using data members not wrapped in properties in data types. XSL itself provides a better structured approach for code reuse. Being able to use localized programming language constructs is at the same time trivial (replace this with that), expensive (you have to translate the documentation) and not that useful (you freeze the language and cut the programmers off from the recent developments in the language). Languages tend to use English keywords regardless of the culture of their designer because: 1. no matter how deep you go, there is always a place where you have to switch to English in order to refer to some precedent technology, 2. the English words/roots used in the language design often have a slightly different meaning from the English source, 3. they are sufficiently few to be learned easily; it may be harder to grasp what they actually mean in the particular context. (Toy languages for children make an exception, of course; however, even children tend to mock them nowadays.) Best regards, Chris
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
DOMTokenList, as an object, is semantically unordered, therefore an arbitrary ordering can be used for enumeration. The item method of DOMTokenList provides an enumerator and imposes such an ordering. Since no other enumerator is available to counter the claim, it may be tempting to say, as a simplification, that DOMTokenList itself is ordered. I would rather discourage you from putting it that way though because it precludes inventing another enumerator in the future or as an extension. HTH, Chris
Re: [whatwg] Annotating structured data that HTML has no semanticsfor
I do not think anybody in WHATWG hates the CURIE tool; however, the following problems have been put forward: Copy-Paste The CURIE mechanism is considered inconvenient because is not copy-paste-resilient, and the associated risk is that semantic elements would randomly change their meaning. Link rot CURIE definitions can only be looked up while the CURIE server is providing them; the chance of the URL becoming broken is high for home-brewed vocabularies. While the vocabularies can be moved elsewhere, it will not always be possible to create a redirect. Chris
Re: [whatwg] Annotating structured data that HTML has nosemanticsfor
Links do not contribute to the behavior the meaning of the text contained within them and not to its meaning. which does not depend on whether the link is broken or not. Moreover, whether the linked resource can be retrieved at all depends on the URI scheme, as in href=mailto:u...@domain;. The advertised advantage of CURIE prefixes is that the metadata declaration can be retrieved and looked up, and that can influence the meaning of the text thus marked. Therefore, link rot is a bigger problem for CURIE prefixes than for links. I think the original URL corresponding to a reversed domain prefix is irrelevant, and attempts to reconstruct it are futile anyway. Nonexistent features are better than features that decay progressively, at least as far as a specification is concerned. Best regards, Chris
Re: [whatwg] Link rot is not dangerous (was: Re: Annotating structured data that HTML has nosemanticsfor)
I understand that there are ways to recover resources that disappear from the Web; however, the postulated advantage of RDFa you can go see what it means simply does not hold. The recovery mechanism, Web search/cache, would be as good for CURIE URL as for domain prefixes. Creating a redirect is not always possible and the built-in redirect dictionary (CURIE catalog?) smells of a central repository. This is no better than public entity identifiers in XML. Serving the vocabulary from the own domain is not always possible, e.g. in case of reader-contributed content, and only guarantees that the vocabulary will be alive while it is supported by the domain owner. (WHATWG wants HTML documents to be readable 1000 years from now.) It is not always practical either as it could confuse URL-based tools that do not retrieve the resources referenced. All this does not imply, of course, that RDFa is no good. It is only intended to demonstrate that the postulated advantage of the CURIE lookup is wishful thinking. Best regards, Chris
Re: [whatwg] Link rot is not dangerous
Classes in com.sun.* are reserved for Java implementation details and should not be used by the general public. CURIE URL are intended for general use. So, I can say Well, it is not the same, because it is not. Cheers, Chris
Re: [whatwg] Link rot is not dangerous
Serving the RDFa vocabulary from the own domain is not always possible, e.g. when a reader of a Web site is encouraged to post a comment to the page she reads and her comment contains semantic annotations. The probability of a URL becoming unavailable is much greater than that of both mirrored drives wearing out at the same time. (data mirroring does not claim it protects from fire, water, high voltage, magnetic storms, earthquakes and the like; it only protects you from natural wear.) The probability of ultimately losing data stored in one copy is 1; the probability of a URL going down is close to 1. So, RAID works in most cases, CURIE URL do not (ultimately) work in most cases. Disappearing CSS is not a problem for HTML because CSS does not affect the meaning of the page. Disappearing scripts are a problem for HTML but they are not a problem for HTML *data*. In other words, script-generated content is not guaranteed to survive, and there is nothing we can do about that except for a warning. Such content cannot be HTML-validated either. In general, scripts are best used (and intended) for behavior, not for creating content. External SVG files do not describe existing content, they *are* (embedded) content. If a HTML file disappears, it becomes unreadable as well, but that problem obviously cannot be solved from within HTML :-) HTML should be readable in 1000 years from now was an attempt to visualize the intention of persistence. It should not be understood as best before, of course. If the author chooses to create a redirect to a well-known vocabulary using a dependent vocabulary stored at his own site in order to prevent link rot, tools that recognize vocabulary URL without reading the corresponding resources will be unable to recognize the author's intent, and for the tools that do read the original vocabulary will still be unavailable, so this method causes more problems than it solves. Cheers, Chris
Re: [whatwg] Link rot is not dangerous
The problem of cybersquatting of oblique domains is, I believe, described and addressed in tag URI scheme definition [RFC4151], which I think is something rather similar to the constructs used for HTML microdata. I think that document is relevant not only to this discussion but to the whole concept. IMHO, Chris
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
If a token list represented an ordered set, it could not be sorted to get an item because the host would have to preserve the original (document) order of tokens. Chris
Re: [whatwg] Micro-data/Microformats/RDFa InteroperabilityRequirement
The main problem with prefixes is that the meaning of prefixes is not preserved when a code fragment is pasted elsewhere, so that prefixed names can end up meaningless or having an entirely different meaning from what the author had intended. A similar problem arises with DTD entities (indeed, DTD entities could be used instead of prefixes). HTH, Chris
Re: [whatwg] rel=license example
The rel=license example in http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#li nk-type-license looks like: body h1Kissat/h1 nav a href=../Return to photo index/a /nav img src=/pix/39627052_fd8dcd98b5.jpg pOne of them has six toes!/p ... /body I would say that this particular example represents a figure with caption. IMHO, Chris
Re: [whatwg] Section 3 semantics and structure
HTML5 elements live in the DOM, and markup creates two (preferable) ways to persist HTML5 documents and fragments. But in principle you could persist them as JSON equally well (probably making your site inaccessible to bots), with a few framework exceptions just to bootstrap the browser. It is quite surprising at the first sight. HTH, Chris
Re: [whatwg] notes on current HTML5 draft
One thing XHTML(2) does not provide is resilience to invalid code, which is very important for sites featuring third-party content like advertisements, or user-generated content like blogs. Script-only add-ons like database access and Web sockets in HTML5 are a big advantage for Web applications as well. I would not consider an exhaustive list of serialization issues in various modes appropriate for the specification itself; this is covered in the FAQ and it is a straightforward conclusion from the features and limitations of the media involved (which are specified). Best regards, Chris
Re: [whatwg] code attributes
Automatic conversion from Microsoft Word to HTML is doomed to fail because the document models and the requirements are different. The best you can get is a tree of DIVs and SPANs with Word-specific classes. Anything better needs a serious and thoughtful remake by the editor. HTH, Chris
Re: [whatwg] size attribute
Do you mean that the vendors will correctly interpret references to characters as references to glyphs but they will fail to understand references to glyphs as themselves? That would be rather weird, IMHO. Chris
Re: [whatwg] size attribute
Regarding 4.10.4.2.4 The size attribute URL:http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html# the-size-attribute: The user does not see characters, she sees glyphs. If the text input control uses a variable-spaced typeface, the user agent must consider the maximum glyph width for the worst case (WWW in Latin or whatever), which may be excessive, or resize the control on the fly (causing a reflow, which would be unexpected and annoying). My text was intended as an amendment to the first sentence only. In particular, I think that the comment about ligatures is worth including. HTH, Chris
Re: [whatwg] dl definition issue
My explanation: Since the terms defined within a DL are normally unique (each term is defined exactly once), DL is inappropriate for marking up dialogue where the speakers talk in turns. HTH, Chris
Re: [whatwg] size attribute
The algorithm [1] for converting a character width to pixels is good indeed, except that it should be formulated in terms of glyphs and not characters because stand-alone characters are not displayed or perceived as such for some scripts. If the primary font for which the algorithm is being run comprises several scripts, as it typically does, characters of the script of the effective language of the control should take overwhelming weight in the average. This algorithm does not fulfill the requirements for the size attribute formulated in section 4.10.4.2.4 [2]: when it is applied, it may happen that the user agent will not be able to allow the user to see the whole text it should be able to allow. The requirement should be modified to match the effect of the algorithm. IMHO, Chris --- [1] URL: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax .html#converting-a-character-width-to-pixels [2] URL: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#attr- input-size
Re: [whatwg] dl definition issue
IMHO the one definition rule is common knowledge and belongs to what constitutes reasonable content; the HTML specification should not try to replace common sense or enforce logical correctness of the author's publication. Chris
Re: [whatwg] code attributes
A CODE element can belong to a class related to the programming language, e.g. * CODE class=HTML * CODE class=JavaScript * CODE class=Python A future version of CSS can provide a property for syntax coloring. IMHO, Chris
Re: [whatwg] size attribute
Using the word glyph instead of character, where appropriate, obviously does not improve the readability of the specification. However, not using the word glyph makes that part simply incorrect for a large number of people whose culture has the disadvantage of being ignored by the leading technological powers. I can understand that, and I can understand that this distinction is pedantry to you because you never see it in practice. All I have to say is that it is very sad. Cheers, Chris
Re: [whatwg] Exposing EventTarget to JavaScript
As a reminder, the syntax {new Option()} (Netscape DOM) is deprecated to the
syntax {document.createElement(OPTION)} (W3C DOM). The requested syntax
{new Event()} would be inconsistent with that design decision. OTOH, the
syntax {new XMLHTTPRequest()} has already been adopted, perhaps because
{document.createXMLHTTPRequest()} would be too specific?
A bit confused,
Chris
Re: [whatwg] HTML as a text format: Should title be optional?
The DOCTYPE is required and it should be. That way, the text introduces itself and instructs the reader about the expected renderer (in absence of external metadata). I have seen several products (mail readers and proxies, on-line help systems, fora etc.) trying to interpret every text as HTML, even if that was not what the author intended. It is safer to interpret every text as plain, unless it starts with a DOCTYPE prologue. This is especially important with HTML fragments. Chris
Re: [whatwg] About Descendent Tags
The header element is not for the page header, it is for grouping section headings, and the tag name chosen for this element is misleading. HTH, Chris
Re: [whatwg] About Descendent Tags
A group of headings looks as follows: header h1 Romeo and Juliet/h1 h3 a tragedy in Italian style/h3 /header This is meant to replace the clumsy HTML4 way: H1 Romeo and Juliet BR SMALL a tragedy in Italian style/SMALL /H1 HTH, Chris
Re: [whatwg] Start position of media resources
I guess I would prefer a DOM property to retrieve the declared start time of embedded media to an explicit attribute. It would me more consistent and tamper-proof. Chris
Re: [whatwg] [html5] Pre-Last Call Comments
Character set x-x-big5 cannot be registered because it is private. Now that classid is gone, what will be the workaround for ActiveX objects where they are needed? 1. Ask Windows browsers to support Type=application/x-oleobject;classid=...? 2. Use a custom DTD with classid for validation? 3. Use a custom type application/vnd.acme-fancy-control+oleobject for every control? 4. Rewrite everything Silverlight? 5. Ask the developers to keep their pages HTML4? Of course, such things are inherently nonportable but they are widely used. It would be nice to have a way to validate them. Chris
Re: [whatwg] [html5] Pre-Last Call Comments
The specification forbids the authors using undefined elements and attributes; a document containing classid will not be valid. Still, the site hosting the controls will need a way to test validity of pages for QA. Chris
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
I suppose that converting a string to uppercase is an action relevant only to cases where only ASCII character set is allowed in the argument, such as HTML element names. Within this restricted application domain, converting to uppercase has the same effect as converting to uppercase ASCII. IMHO, Chris
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
data-* attributes allow XML name characters and they are converted to lower case in HTML (ASCII, AIUI). BTW, editorial correction for 3.3.3.8 http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#embedd ing-custom-non-visible-data : should be its name contains no characters in the range (because an attribute contains its value). Chris
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
An attribute named data-K is allowed.
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
It seems that getting the element name is not covered at all, it is a core interface, so definitions in the HTML specification do not apply. Chris
Re: [whatwg] Notifications UI for Persistent Workers
I think text input controls should be disabled for HTML notifications so that notification windows cannot benefit from posing as something else. Chris
Re: [whatwg] Input type for phone numbers
Phone numbers do have a strictly defined format, and the definition is provided by ITU-T E.123. HTH, Chris.
Re: [whatwg] Web Addresses vs Legacy Extended IRI (again)
It is not clear that the server will be able to correctly support various representations of characters in the path component, e.g. identify accented characters with their decompositions using combining diacritical marks. The peculiarities can depend on the underlying file system conventions. Therefore, if all representations are considered equally appropriate, various resources may suddenly become unavailable, depending on the encoding decisions taken by the user agent. Chris
Re: [whatwg] Worker feedback
Scripts, and worker scripts in particular, should use application media type; using text/javascript is obsolete. [RFC4329#3]. Chris
Re: [whatwg] Canvas - toTempURL - A dangerous proposal
IFRAME where SRC=javascript:... has the same disk full problem as Canvas.toTempURL, and a DOS attack can also be launched simply by creating a large array that will fill the hard drive with virtual memory. In general, handling OOM conditions is not covered by the specification. Chris
