Re: [whatwg] What exactly is contentEditable for?
I've been following this thread for a little while. I too think that the contentEditable is not done quite right. My biggest problem with it (and this was pointed out before) is that it is a half-way effort: there is markup that enables the editing, but there is no markup that provides any information about submission for the edits. IMHO, this is incomplete. If you provide means for entry, it shall be your responsibility to provide means for exit. I was surprised to learn that WF2 spec does not support rich textarea. I still can't figure out why. Again, IMHO, the contentEditable attribute represents a shift of paradigm in Web markup: it suggests that the actual markup of the page could be the target of user manipulation. Prior to it, users were confined to forms elements. It's not that I mind the shift. But this shift is kind of huge, and I don't think it's wise to shift just bits and pieces. :DG
[whatwg] Conformance requirements on conformance checkers
Quoting from http://whatwg.org/specs/web-apps/current-work/#parsing : Conformance checkers must report all parse error conditions (both hard and easy errors) to the user, but may apply error correction algorithms (those described in the spec for easy errors, and those reverse-engineered from other UAs for hard errors) in an attempt to continue past the location of the error and find the remaining errors. The latter part of the sentence somewhat implies that the parser might not be required (in the MUST sense) continue to find all errors. However, the start of the requirement could be clearer. I'd prefer something like this: Conformance checkers must report at least one parse error condition to the user if one or more parse error conditions exist in the document and must not report parse error conditions if none exist in the document. Conformance checkers may report more than one parse error condition if more than one parse error conditions exist in the document. Conformance checkers are not required to recover from parse errors (not even easy parse errors). Rationale: Considering the purpose of a conformance checker, it should be sufficient for the conformance checker to find out whether the document is conforming. Additional reporting should be a feature bargain between the conformance checker developer and users--not a hard spec requirement. Besides, XHTML flavor conformance checking is likely to stop on the first well-formedness error anyway. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[whatwg] [html5] The DocumentFocus interface
I propose to rename the currentFocus attribute to activeElement for historical reasons.[1] (Both Internet Explorer and Opera implement it in that way.) Kind regards, Anne [1]http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/activeelement.asp -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] WA1: li processing
# If the attribute's value cannot be converted to a number, it is treated # as if the attribute was absent. The attribute has no default value. The attribute's value is treated as if the attribute was absent doesn't make a whole lot of sense to me. Did you mean a different 'it'? # The value attribute is processed by the parent ol element, if there is one. # If there is not, the attribute has no effect. The first sentence makes no sense. What does it mean for an element to process another element's attribute? I thought the UA processed the attributes. Is the second sentence meant to imply that when the parent is not ol the value DOM attribute reflects a missing 'value' attribute rather than whatever value the 'value' attribute actually has? If so, you should make it more explicit. If not, you should make /that/ explicit. # Each subsequent item in the list has the ordinal value given by its value # attribute, if it has one, or, if it doesn't, the ordinal value of the # previous item, plus one. The instructions in the ol section seem to omit any reference to the number conversion step described in the li section. Here's a suggestion: Replace # If the value attribute is present, user agents must convert the # value to a numeric type, truncating any fractional part, in order # to determine the attribute's value. If the attribute's value cannot # be converted to a number, it is treated as if the attribute was # absent. The attribute has no default value. # # The value attribute is processed by the parent ol element, if # there is one. If there is not, the attribute has no effect. with | If the value attribute is present, user agents must convert the | value to a numeric type, truncating any fractional part, in order | to determine the attribute's numerical value. If the attribute's | value cannot be converted to a number or the attribute is missing | (or the parent element is not an ol element)?, then the attribute | has no numerical value. and # Each subsequent item in the list has the ordinal value given by # its value attribute, if it has one, or, if it doesn't, the ordinal # value of the previous item, plus one. with | Each subsequent item in the list has the ordinal value given by | its value attribute's numerical value, if it has one, or, if it | doesn't, the ordinal value of the previous item plus one. (Either way, you should remove the comma before plus one.) ~fantasai
Re: [whatwg] [WF2] Readonly and default pseudoclass matching
On Sun, 31 Jul 2005, Matthew Raymond wrote: Note that the text above was reviewed by the editor of the CSS3 UI spec and given the all-clear. Of course he gave it the all clear. He's the one who wrote the disputed portion of the spec in the first place. Which disupted section of which spec? For CSS: http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-ro-rw For WF2: http://whatwg.org/specs/web-forms/current-work/#relation CSS isn't being disputed here (or if it is, it's the wrong mailing list). And the editor of the CSS3 UI spec didn't write the disputed part of the WF2 spec; I wrote the latter. If the disputed section is the one I wrote (i.e. the one quoted above) then no, he didn't; I wrote it. I never said he wrote it. You said Of course he gave it the all clear. He's the one who wrote the disputed portion of the spec in the first place. -- if you didn't mean that then I've no idea what you meant, sorry. You altered WF2 to make it repeat aspects of what he wrote (CSS3-UI). Obviously the person who wrote the sections of the CSS3-UI spec you're drawing from is going to agree with corrections that reinforce his own content. Ok, I'm glad you agree that it reinforces CSS3 UI and doesn't conflict with it. That is what was intended. We can't really do anything else, since CSS3 UI isn't one of the specs WHATWG is doing. What was wrong with the revision I suggested?... | Matches form control elements that have the readonly attribute set, | and to which the readonly attribute applies (thus radio buttons will | never match this, regardless of the value of the attribute), as well | as other elements defined by this specification that are defined as | read-only under the CSS3 Basic User Interface Module. Well, the second part doesn't say anything (it's redundant with CSS3 UI). The whole point of the section is to say which elements defined by WF2 match the definition of CSS3 UI. In a scenario with script, when would you disable the input readonly element specifically and in markup rather than disabling a parent fieldset? There might not be a parent fieldset. In any case, what's the difference? So, when am I going to need to disable a single read-only control independently of other controls? Not seeing a use case here. One possibility would be viewing a database view where the user has rights to edit a field on some records but not others (e.g. allowed to edit the customer's start date but only if the customer hasn't started yet). As you flip through records, the field becomes read-only or not. It's not disabled, because the data is still relevant, even though it can't be edited. (Indeed in XForms enabled is spelt relevant, IIRC.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Pattern Hint
On Wed, 3 Aug 2005, Dean Edwards wrote: I know this has been suggested before, and was rejected, but I would quite like to see a pattern hint attribute added to Web Forms 2.0. With more complex input controls we should spare a thought for the poor user. There is one. It's the title attribute. See: http://whatwg.org/specs/web-forms/current-work/#patternTitle Authors can also include the help information inline, next to the pattern. I'm wary of adding additional help mechanisms. Authors haven't exactly gone out of their way to use the existing mechanisms. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Pattern Hint
On Thu, 4 Aug 2005, Dean Edwards wrote: I'm also concerned about pattern mismatches. If a form is invalid the UA is supposed to feed back information to help the user complete the form. http://whatwg.org/specs/web-forms/current-work/#form-submission For most types, pattern mismatches are easy to explain to the user - Please enter a valid time (format HH:MM:SS).. For a complex pattern this is more difficult. The UA can't assume that the title attribute is going to help in this situation so must fall back to a generic Pattern mismatch. Actually, the way the spec is written now, the UA _can_ assume that the title attribute is going to help. In fact it is encouraged. Assume that your proposal (hint) is spelt title and implement it like that. (Including the little button you wanted for hint). That is the intent of the spec at the moment. My concern is one of usability. We have provided a mechanism for entering complex patterns, we should also provide a mechanism for helping end-users enter these patterns. I agree. But I don't see why the existing mechanisms aren't enough. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] What exactly is contentEditable for?
On Fri, 5 Aug 2005, dolphinling wrote: Perhaps I've missed something, but while I've seen lots on what contentEditable does and how it works and how various other things are associated with it, I've never actually seen anything explaining *why* it exists. So... what's it good for? Rich text editing, such as with blog editing software or forum software. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] What exactly is contentEditable for?
On Mon, 15 Aug 2005, Lachlan Hunt wrote: How is [contentEditable] any different from a text area form control with a specified accept type of text/html, which would allow a UA to load any external editor (eg. XStandard) or degrade to a regular text area? contentEditable is implemented. textarea type=text/html is not. That would be a far better option than using contentEditable, which is not only conceptually broken, but *all* implementations of it are so incredibly broken, that trying to standardise it is like dragging a dead horse through mud. There may be some truth to that, but contentEditable also has other benefits, like integration with the DOM, and the ability to seemlessly integrate with the page. For example, on a wiki, you can be browing the content, and then toggle one area so it is contentEditable, edit it, and submit that, all asynchronously and without having to switch in a textarea or anything like that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] What exactly is contentEditable for?
On Tue, 23 Aug 2005, Hallvord Reiar Michaelsen Steen wrote: Could we extend contentEditable in a way that would let the UA offer a non-scripting UI for saving the edited page? For example using the form attribute from WF2? What's wrong with File Save ? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] What exactly is contentEditable for?
On Tue, 23 Aug 2005, Dimitri Glazkov wrote: I was surprised to learn that WF2 spec does not support rich textarea. I still can't figure out why. Time. It's on the list for WA1/WF3 (although currently contentEditable is the way I intend to address the need). Again, IMHO, the contentEditable attribute represents a shift of paradigm in Web markup: it suggests that the actual markup of the page could be the target of user manipulation. Prior to it, users were confined to forms elements. Actually, originally, HTML was supposed to be user editable always. Much like in Amaya. So contentEditable is more of a compromise between the original intent of the Web and the don't let them modify it! attitude that has grown since. (I'll look into what you suggested about new markup for saving, etc.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] removing attributes
On Fri, 5 Aug 2005, [UTF-8] Olav Junker Kjær wrote: Is it possible to remove a constraint like maxLength (on input elements) through script, eg. by setting it to null? By default a field does not have any maxlength constraint, so it would seem natural that if you set a constraint through script, it could be removed again. Yes, there are a number of DOM attributes that map to content attributes. This is already the case in DOM2 HTML. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [wf2] Section 6.2, is xmlns an attribute
On Sat, 6 Aug 2005, Anne van Kesteren wrote: I was wondering about section 6.2: http://whatwg.org/specs/web-forms/current-work/#seeding Should 'xmlns' be considered as an attribute? I was specifically wondering about have no other non-namespaced attributes. Clarified. How should those elements be processed if they have non-namespaces attributes specified by the way? That seems to be undefined. All other elements in the file must be ignored. (I admit that I have not read it carefully.) (No worries, I didn't read your e-mail very carefully either!) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [wf2] textInput event?
On Sat, 6 Aug 2005, Anne van Kesteren wrote: Why does Web Forms 2 not deal with the textInput event from DOM Level 3 Events? http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-textInput Is there something about DOM 3 Events' description that is ambiguous in terms of WF2? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Re: 1 webpage != 1 document
On Wed, 17 Aug 2005, Jep Castelein wrote: Am I right in saying that section and especially article could promote the use of multiple documents in 1 webpage? That depends on what you mean by document. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] What exactly is contentEditable for?
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 23 Aug 2005, Hallvord Reiar Michaelsen Steen wrote: Could we extend contentEditable in a way that would let the UA offer a non-scripting UI for saving the edited page? For example using the form attribute from WF2? What's wrong with File Save ? Save where? How? What? :DG
Re: [whatwg] What exactly is contentEditable for?
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote: Actually, originally, HTML was supposed to be user editable always. Much like in Amaya. So contentEditable is more of a compromise between the original intent of the Web and the don't let them modify it! attitude that has grown since. I understand (and appreciate) the sentiment, but that's not how HTML had developed. Amaya's simplistic PUT is not going to cut it for most of today's managed content. Web pages have become compositions of resources, and something a little more sophisticated is needed to specify how the edits are passed on to the server. As you know, there is already a scheme for communicating server's expectations on input -- forms. I can't see how contentEditable fits in this scheme. The attribute only specifies whether the area is possible to edit. It does not specify how the UA is to communicate it back. It just doesn't seem kosher to leave it as is. And answering your earlier comment, I understand that it's just a couple of lines of code to provide that communication. The problem is that it's not a consistent or standardized way, which makes it next to impossible to determine how this communication is handled without actually executing the code. Shooting from the hip, I would rather see something like this: textarea type=text/html src=#mainPageContent id=mainPageContentEditor/textarea Where the src attribute points to an element (or the whole document, if you want to). The element and its children/descendants may or may not have contentEditable attribute set, thus regulating which parts of the fragment is editable. At least now you are using the same form scheme to specify how the server would like to receive this data. :DG
Re: [whatwg] What exactly is contentEditable for?
On Tue, 23 Aug 2005, Dimitri Glazkov wrote: As you know, there is already a scheme for communicating server's expectations on input -- forms. I can't see how contentEditable fits in this scheme. It doesn't. If you want contentEditable to be submitted, you need to use a line of script. And answering your earlier comment, I understand that it's just a couple of lines of code to provide that communication. The problem is that it's not a consistent or standardized way, which makes it next to impossible to determine how this communication is handled without actually executing the code. True. But it is what IE does. Our hands are pretty much tied on this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] What exactly is contentEditable for?
On Tue, 23 Aug 2005, Dimitri Glazkov wrote: On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 23 Aug 2005, Hallvord Reiar Michaelsen Steen wrote: Could we extend contentEditable in a way that would let the UA offer a non-scripting UI for saving the edited page? For example using the form attribute from WF2? What's wrong with File Save ? Save where? How? What? On disk. By serialising the DOM. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] textarea accept attribute -- solution to rich text editing in WF2?
I may have spoken too soon on the absence of rich text editing textarea in WF2. Looking at the spec, there is an accept attribute for the textarea element, and its description fits the bill very nicely. If we have accept=text/html or accept=application/xml+xhtml, it is totally up to the UA to provide a specialized editor -- the HTML editor in this case. Am I right on this one? :DG
Re: [whatwg] textarea accept attribute -- solution to rich text editing in WF2?
On Tue, 23 Aug 2005, Dimitri Glazkov wrote: I may have spoken too soon on the absence of rich text editing textarea in WF2. Looking at the spec, there is an accept attribute for the textarea element, and its description fits the bill very nicely. If we have accept=text/html or accept=application/xml+xhtml, it is totally up to the UA to provide a specialized editor -- the HTML editor in this case. Am I right on this one? Yes, but note that the UA is not required to perform any validating or anything. In practice I doubt we'll ever see useful implementations (whereas we already have useful, and used, implementations of the contentEditable feature). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] What exactly is contentEditable for?
Ian Hickson wrote:
On Mon, 15 Aug 2005, Lachlan Hunt wrote:
How is [contentEditable] any different from a text area form control
with a specified accept type of text/html, which would allow a UA to
load any external editor (eg. XStandard) or degrade to a regular text
area?
contentEditable is implemented. textarea type=text/html is not.
And, as I demonstrated in an earlier e-mail with the widgEditor I linked
to, it's not hard for an author to provide a script that converts the
textarea to a WYSIWYG editor using the contentEditable DOM interface.
It's not much different from the scripts that are being written to add
support for other extensions in today's browsers.
That would be a far better option than using contentEditable, which is
not only conceptually broken, but *all* implementations of it are so
incredibly broken, that trying to standardise it is like dragging a dead
horse through mud.
There may be some truth to that, but contentEditable also has other
benefits, like integration with the DOM, and the ability to seemlessly
integrate with the page. For example, on a wiki, you can be browing the
content, and then toggle one area so it is contentEditable, edit it, and
submit that, all asynchronously and without having to switch in a
textarea or anything like that.
That's a reasonable argument for standardising the DOM interface for it,
but not for including contentEditable as an attribute in the markup,
which is what I'm against the most.
Although I am against the use of contentEditable in general, that's
mostly because {a) all the implementations of it are broken and (b) the
way it was designed is too presentationally oriented for a semantic
markup language - it basically suffers from the same design flaws as
every other WYSIWYG editor.
Using the wiki example, a script could be provided which captures the
events for the edit this links and dynamically makes the content for
that section editable using the contentEditable DOM interface. Scripts
would also be used to handle the submission.
However, without script those links should fall back to the way they
currently work, which is to load a seperate page with the editable
markup in a textarea for the user. Additionally, that textarea could
have an accept=text/html attribute, from which (even without JS
enabled) the user agent could choose to load an HTML editor for the user
(whether that be for just providing syntax highlighting in code view or
a WYSIWYG style editor).
Personally, I'd like to see it better integrated with the DOM 2 Range
interface, so the scripts could work with the nodes a little easier and
which I'd like to see more widely implemented.
--
Lachlan Hunt
http://lachy.id.au/
