[whatwg] Incomplete user-input in some input types
Proposal: Making an input element invalid state if the input has an invalid string specified by a user with browser UI. An invalid string means a string which doesn't match to a required format defined by a type. e.g. If a user typed - to input[type=number], input.validity.valid would be false and form submission would be prevented. A. In such case, make input.validity.typeMismatch true, or B. Introduce new IDL attribute to ValidityState. input.validity.invalidUserInput? This behavior should be applied to the following types: number, color, date, datetime, datettime-local, month, time, and week Background: If an input type is implemented as a text field, it is very hard for UA to reject invalid strings for the type. For example, - is not a valid floating-point number, but UA can't prevent users from typing -. So the field can contain invalid strings though its value IDL attribute is empty. If a user tries to submit the form in such situation, the field is valid unless the required attribute is specified. WebKit clears the invalid string when the field loses focus or the form is submitted. A sanitized value (empty string) is submitted. Opera doesn't clear the invalid string. It silently submits a sanitized value (empty string). IE10 has a behavior similar to WebKit. However if a user type -1abc, -1abc is submitted. I don't like clearing user input. It's not a good user experience. Users don't expect their input strings are cleared by UA. Also, I don't like submitting empty value silently. Users expect their input strings are submitted. I think the best UI is to notify users about a field has an invalid string, and give a chance to correct it. Applying the standard form validation mechanism must be reasonable. -- TAMURA Kent Software Engineer, Google
[whatwg] Problem in the Section 4 Elements of HTML = 4.4 Sections = 4.4.2 The Section element
Hello Contributors. I recently started checking the specs and i can't help but notice the weird formation of the tags in this section http://www.whatwg.org/specs/web-apps/current-work/#dfnReturnLink-10 can anybody tell me if this is known/on purpous Thanks, Kevin Deamandel
Re: [whatwg] Problem in the Section 4 Elements of HTML = 4.4 Sections = 4.4.2 The Section element
I assume you're referring to tags written as: Html Head Title The reason for this is to prevent undesired whitespace in markup, while preserving indentation. Whitespace in HTML is preserved between tags, but it is not preserved within. ☺ On Thu, Sep 13, 2012 at 1:43 PM, Kevin Deamandel kdeam...@gmail.com wrote: Hello Contributors. I recently started checking the specs and i can't help but notice the weird formation of the tags in this section http://www.whatwg.org/specs/web-apps/current-work/#dfnReturnLink-10 can anybody tell me if this is known/on purpous Thanks, Kevin Deamandel
Re: [whatwg] Problem in the Section 4 Elements of HTML = 4.4 Sections = 4.4.2 The Section element
2012-09-13 20:43, Kevin Deamandel wrote: I recently started checking the specs and i can't help but notice the weird formation of the tags in this section http://www.whatwg.org/specs/web-apps/current-work/#dfnReturnLink-10 When I try to use the one-page version that this URL refers to, it freezes or almost freezes my browser on a regular basis. I'm pretty sure it's not just me. So I very much prefer referring to the multi-page version, e.g. http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-section-element And I suppose by weird formation you mean the example that starts with !DOCTYPE Html Html Head Title Graduation Ceremony Summer 2022/Title /Head Body H1 can anybody tell me if this is known/on purpous My guess is that it's an accidental result of some software used to maintain the document. It's not incorrect, just odd, because it deviates from the coding style used otherwise, both in the use of spaces between tag close () and in casing (capitalized tag names). Yucca
Re: [whatwg] Problem in the Section 4 Elements of HTML = 4.4 Sections = 4.4.2 The Section element
On Thu, Sep 13, 2012 at 11:09 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: And I suppose by weird formation you mean the example that starts with !DOCTYPE Html Html Head Title Graduation Ceremony Summer 2022/Title /Head Body H1 can anybody tell me if this is known/on purpous My guess is that it's an accidental result of some software used to maintain the document. It's not incorrect, just odd, because it deviates from the coding style used otherwise, both in the use of spaces between tag close () and in casing (capitalized tag names). No, it's intentional. Hixie purposely varied his style across examples, to show that certain variances in the syntax were allowed and perfectly fine. ~TJ
Re: [whatwg] Problem in the Section 4 Elements of HTML = 4.4 Sections = 4.4.2 The Section element
2012-09-13 21:15, Tab Atkins Jr. wrote: Hixie purposely varied his style across examples, to show that certain variances in the syntax were allowed and perfectly fine. Oh, I see. It's somewhat questionable if you ask me. Varying the syntax _within a document_ is something different from the liberty of choosing one's style. But I guess the reader is assumed to treat the examples as quotations that reflect different styles (and style is consistent within each example). Still, I wouldn't do that. I don't think authors really need to be reminded of the possibility of writing Section instead of the most common way, section, and the next common one, SECTION. People who have some special reason for writing, say, sEcTIon claSs = foo should probably check the syntax definition details if in doubt, and just go ahead (maybe using a validator) if not. Yucca
Re: [whatwg] Problem in the Section 4 Elements of HTML = 4.4 Sections = 4.4.2 The Section element
I personally find that having such an uncommon syntax is actually distracting. On Thu, Sep 13, 2012 at 2:28 PM, Jukka K. Korpela jkorp...@cs.tut.fiwrote: 2012-09-13 21:15, Tab Atkins Jr. wrote: Hixie purposely varied his style across examples, to show that certain variances in the syntax were allowed and perfectly fine. Oh, I see. It's somewhat questionable if you ask me. Varying the syntax _within a document_ is something different from the liberty of choosing one's style. But I guess the reader is assumed to treat the examples as quotations that reflect different styles (and style is consistent within each example). Still, I wouldn't do that. I don't think authors really need to be reminded of the possibility of writing Section instead of the most common way, section, and the next common one, SECTION. People who have some special reason for writing, say, sEcTIon claSs = foo should probably check the syntax definition details if in doubt, and just go ahead (maybe using a validator) if not. Yucca
Re: [whatwg] Problem in the Section 4 Elements of HTML = 4.4 Sections = 4.4.2 The Section element
I second this Scott -Kevin On Thu, Sep 13, 2012 at 8:31 PM, Scott González scott.gonza...@gmail.com wrote: I personally find that having such an uncommon syntax is actually distracting.
Re: [whatwg] Should editable elements have placeholder attribute?
On Fri, Sep 7, 2012 at 6:03 AM, Aryeh Gregor a...@aryeh.name wrote:
On Thu, Sep 6, 2012 at 6:30 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Note that this shouldn't be hard to do without magic. Just something
like this in the UA style sheet:
[contenteditable]:empty { min-height: 1em; }
contenteditable is not a boolean attribute -- you'd need to do
[contenteditable=true]. But I don't think that works right if there's
leading or trailing whitespace or similar. In theory, this might do
the trick:
:read-only :read-write { min-height: 1em; }
except that WebKit doesn't let editability affect
:read-only/:read-write, because it uses a CSS property to track
editability. (Gecko uses a per-node boolean flag and just iterates
through ancestors when necessary.)
Also, :empty won't help if there's a child that's only whitespace, like
div contenteditable
/div
or
div contenteditable /div
which would be a case we'd want to handle. But if you omit the
:empty, it would break if there were smaller-than-usual text.
Also, 1em isn't the same as if you put some text in it. Generally,
typing some text is supposed to create a p, which might make it
substantially taller than 1em depending on margin collapsing, right?
You'd know this better than me.
So I don't think this would be so trivial to spec. If you can come up
with something that works, I'm all ears!
On Thu, Sep 6, 2012 at 6:53 PM, Ojan Vafai o...@chromium.org wrote:
While WebKit does put the magic br in, that's not what avoids the
collapsing in this case. If you set the innerHTML to , it still doesn't
collapse. We actually hard-code that editing hosts don't collapse.
I know -- this is the non-standard special case I referred to. :)
This is technically not per spec at present, but I wouldn't object to
standardizing it if it can be done reasonably. The only thing is, I'm
not sure it can be. I'm not convinced that hardcoding editing logic
into CSS is a good idea unless it's needed for web compat, which I
imagine it's not, because Gecko doesn't do it.
But on the other hand, it looks like everyone but Gecko does do it,
although I'm sure the details are totally different. And it's
certainly nice for usability. So it would be nice if we had some good
way to spec it. I wonder if Opera does it in a saner-to-spec way.
The way I'd want to see this happen is to expose a CSS property that
prevents collapsing empty elements, then we'd add something like the
following to the UA stylesheet:
*[contentEditable=true] { empty-collapse-behavior: no-collapse }
Re: [whatwg] Submitting contentEditable Content In A Form
On Fri, Sep 7, 2012 at 1:07 PM, Alain Couthures alain.couthu...@agencexml.com wrote: Le 07/09/2012 12:32, Mikko Rantalainen a écrit : 2012-09-07 11:57 Europe/Helsinki: Hugh Guiney: JavaScript into, say, a hidden form field. I think that there should be some mechanism to associate contentEditable elements with forms—maybe the combination of contentEditable=true and the presence of @name creates an implicit form control? The value sent to the server could be equivalent to that element's innerHTML. Thoughts? The contenteditable attribute is meant for low level wysiwyg-editor like behavior framework and it is not meant to work standalone without scripting. I'd suggest supporting textarea type=text/html with a built-in HTML wysiwyg editor if any UA wants to support HTML editing without JavaScript. In that case, the UA should provide a scriptable method for detecting for native support of type=text/html. As a result, a CMS system could fallback to e.g. TinyMCE or CKeditor to emulate the missing support. @type should only contain a type name, such as date or number, and text/html is a media type so html would be more appropriate from my point of view. I can mention that XForms has the same problematic and I implemented a wysiwyg editor support in my own XForms implementation with TinyMCE for XForms textarea control. In XForms, the type associated to the target node is used to automatically adapt the control rendering. BTW, I even consider that textarea would be useless if only a multilined type could be supported for the input field. A select field would be an input field for an enumeration... So input tag would cover every possibility! I think this is a problem that we need to address more generally. I'm not sure what the API should look like, but it's not specific to contentEditable. I should be able to make a Web Component that submits specific values with forms based off it's content. If we solve that problem right, it'll be possible to make contentEditable elements submit with forms without extra JS code.
Re: [whatwg] Including HTML more directly into SVG
On Tue, Sep 11, 2012 at 12:37 PM, Elliott Sprehn espr...@gmail.com wrote: On Sep 11, 2012 11:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Sep 11, 2012 at 11:29 AM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: ... Also, how does your proposal address flowing text inside of a path? That's a good question! Presumably you mean that, for example, one might want to have emphasized text in a text-along-a-path flow? I suppose it should be as easy as making them children of a textPath, and setting display:svg to make them obey SVG rendering rules rather than the CSS box model. I mean if you look at the svg flow spec there's an example of text inside a polygon or even text flowing inside of large bubble letters. Similar concept as CSS exclusions, but it doesn't make sense to specify the polygon twice to use that. The SVG flow spec was never implemented by browsers, to my knowledge. I don't understand the relevance of this question. Presumably one could just use CSS Exclusions. A strawman of the JSON spec rewritten with your proposal would be useful. I don't understand this request. Sorry its not the JSON spec, it just had a similar theme (my confusion). I meant could you rewrite the railroad svg from your original email to show how this is better? http://www.xanthir.com/etc/railroad-diagrams/example.html It wouldn't be *significantly* changed in my diagram - I'll still need to measure things, because I need to attach lines to the edges and make other parts respond to the width. My diagram would just benefit from being able to draw a single element rather than a rect+text pair. However, some of my other examples from my original post would be significantly simplified. Anything that needs text-wrapping, or which is simply positioning the text somewhere without needing much coordination with other elements (like some text on or around a graph). ~TJ
Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry
On Tue, 15 Nov 2011, Kinuko Yasuda wrote: Many sites have 'upload your files' feature, like for your photo images. HTML5 allows you to do this via input type=file multiple or drag-and-drop feature, but the current solution does not provide clean solution for cases with folders, files/folder mixed cases, or folders with subfolders cases. For context, back then we have proposed (and implemented) 'directory' attribute for input type=file specifically to upload a directory, but the approach does not provide useful information to webapps about which file comes from which folder, neither does it allow apps to control how and when to enumerate directories (e.g. app cannot show progress meter etc even the enumerating part takes long time). http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html This isn't really about directories, it's a problem with file I/O in general, made worse when there are large numbers of files -- it's just that when you have directories you're more likely to have many files. Other situations also make this difficult, e.g. if the files are on a network drive with high latency, or a removable drive such as a DVD or tape drive. Fundamentally the problem is that the objects in drag-and-drop and in input type=file synchronously expose all the files, and we just don't necessarily have the time to get all the files' sizes before that starts to be noticably slow. We could have the UA show progress UI, but while that could work for input type=file, it would be quite jarring for drag and drop. There are various ways we could fix this if we were starting afresh, but if we're trying to keep backwards compatibility there's basically no solution: the spec already requires this sync API, and pages might depend on it. So we have a problem: do we not fix the problem, do we break all pages always, break all pages but only when the user drags in a lot of files (so authors might not notice), break all pages whenever there's more than one file (so authors will notice but pages still support one file at a time), break pages only when the user drags in one or more directories? There's various ways we could fix the problem, if we're ok with breaking things. We could expose all the files in a flat list, incrementally. We could expose the directory hiearchy, with asynchronous access. If we do incremental access, there's various ways to do that: event-based notification that there's more data; an enumerator / callback mechanism; a lazy array where reading the number of files, or reading the nth file, is asynchronous... We can extend FileList and DataTransferItemList to support this, or we can add a new object that they point to, or we can just update FileList and make DataTransferItemList support the new object... In many cases, exposing the actual hierarchy can reduce the total amount of work that's needed, because many use cases don't actually need to crawl everything. For example, people gave examples of just wanting Subversion's internal .svn directories in a big tree, not the actual data; or indeed in other cases vice-versa. However, both exposing the hiearchy and flattening it have all kinds of risks. It's possible for the user to accidentally expose his entire computer's hard drive without realising it. On some systems (including at least modern Mac OS and Linux OSes, not sure about Windows), it's possible to have hard-link loops. On some systems, it's possible to drag special directories like .., and it's not clear what that would mean. When the user drags files from multiple parts of the file system (e.g. from a Windows virtual folder), it's not clear what parts of the path we should expose -- even exposing just the common parts can expose sensitive information like the profile path if one file is in the user's profile and another is not. Also, none of these solutions helps with DataTransfer.types or exposing the types in DataTransfer.items while the drag is occurring, if the goal is to expose a deep crawl there. If we limit ourselves to just exposing the files that were dragged, then I think the OS will give us the list of files, so the problem is only statting them to get the sizes when you drop. On Tue, 15 Nov 2011, Glenn Maynard wrote: Entry (and subclasses) should also be supported by structured clone. That would allow passing a DirectoryEntry received from file inputs to be passed to a worker. This is something for later, of course, but combined with an API to convert between Entry and EntrySync (and DE/DESync), this would allow using the much more convenient sync API in a worker, even if the only way to retrieve the Entry in the first place is in the UI thread. Any spec can define how they work with the structured clone algorithm. I'll let the Filesystem API editors consider this. On Thu, 5 Apr 2012, Kinuko Yasuda wrote: Based on the feedbacks we got on this list we've
Re: [whatwg] Problem in the Section 4 Elements of HTML = 4.4 Sections = 4.4.2 The Section element
On Fri, Sep 14, 2012 at 4:15 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Sep 13, 2012 at 11:09 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: And I suppose by weird formation you mean the example that starts with !DOCTYPE Html Html Head Title Graduation Ceremony Summer 2022/Title /Head Body H1 can anybody tell me if this is known/on purpous My guess is that it's an accidental result of some software used to maintain the document. It's not incorrect, just odd, because it deviates from the coding style used otherwise, both in the use of spaces between tag close () and in casing (capitalized tag names). No, it's intentional. Hixie purposely varied his style across examples, to show that certain variances in the syntax were allowed and perfectly fine. Might be worth a note in this instance to stop people from wondering? Silvia.
