Re: [whatwg] Handling of collapsed whitespace in contenteditable
Am 21.06.2011 02:16 schrieb Ojan Vafai: It is certainly the case that some large subset of users use spaces to align content, not to mention really care about things like two spaces after periods, etc. One way or another, contentEditable needs to support this. If we were starting with a clean slate, the editing behavior we want is likely whitespace:pre-wrap + some logic about what to do when you put extra spaces at the end of a line*. We should make sure the pre-wrap editing works as well as possible (e.g. doesn't do any of these NBSP shenanigans), but we have to support non-pre-wrap even if it's not the default. So, one way or another, we need to spec this behavior. I agree. I personnally would appreciate a use NBSPs for consecutive spaces setting that can be turned on or off. For BC reasons it will have to be on by default. An author who is aware of this and able to turn this setting off, will also be aware of the possibility to apply white-space:pre-wrap to the contenteditable element. Therefore I suggest to leave this up to the author. It does not look consistent to me to apply different default values for the white-space property based on the contenteditableness of an element. (At least, I would find it easier to answer the question Why do my spaces disappear while typing? than the question Why does my content look different though I use the same CSS for the editor and the target page of the edited text?.)
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On 2011-06-20 21:28, Jonas Sicking wrote: On Mon, Jun 20, 2011 at 7:13 AM, Per-Erik Brodin per-erik.bro...@ericsson.com wrote: On 2011-06-20 12:53, Jonas Sicking wrote: Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. Only custom request headers are matched against the list of simple headers and Host is not a custom header set by the EventSource implementation, hence there is no need to add it to the list. In XHR Level 2 the custom request headers are the author request headers. An option would be to always match the list of simple headers against author request headers only. It seems like you are saying exactly what I was saying? Am I missing something? What I am saying is that currently CORS defines custom request headers and that can be interpreted as all headers that are set by the API implementations (such as Last-Event-ID set by EventSource but not including the headers normally set by the HTTP loader, such as Host), regardless if they are author supplied or not. Since this has the downside that all new specifications that want to use CORS will have to rely on the CORS spec being updated if any new custom headers are going to be used, I agree with your proposal to match only author supplied headers against the list of simple headers. //Per-Erik
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On 2011-06-20 21:59, Ian Hickson wrote: According to the CORS specification, a request is not to be terminated even when the resource sharing check fails. However, when using CORS with EventSource I think it may be justified since the response is typically not returned right away. Not sure what you mean here. Could you elaborate? I misread the sentence Do not actually terminate the request. in the CORS spec as applying to both the resource sharing check pass and failure cases. The Cache-Control request header used with EventSource is not in the list of simple request headers and a preflight request is not really an option here in my opinion. Not sure what you mean by simple request headers. The Cache-Control header isn't a custom header, so it doesn't affect whether you use a preflight or not. I've clarified the spec. OK, is Last-Event-ID also not a custom header then? //Per-Erik
Re: [whatwg] comment on a part of the script execution spec, regarding not fully active documents
On 6/21/11 5:21 AM, Hallvord R. M. Steen wrote: Another issue I noticed is in the text under the heading the javascript: URL scheme - specifically the last otherwise part of the text. This is about trying to navigate a window from a different origin to a javascript: URL. Don't we expect a security exception here? I don't think so, no. In particular, this check needs to happen right before running the script, which happens asynchronously, right? So at that point throwing a security exception doesn't make much sense... -Boris
Re: [whatwg] Handling of collapsed whitespace in contenteditable
On Mon, Jun 20, 2011 at 6:05 PM, Ryosuke Niwa rn...@webkit.org wrote: Problem is that not all user agents, in particular, mail clients support white-space: pre-wrap. Good point. That's pretty much the final nail in the coffin. I'll specify something with nbsp's here, although I don't know how I'll make it work when runs of spaces span multiple text nodes. I'll add a note advising authors to use white-space: pre-wrap, although I doubt many will see or follow it.
Re: [whatwg] Extensible microdata attributes
On 6/14/2011 2:32 AM, Tab Atkins Jr. wrote: On Mon, Jun 13, 2011 at 2:29 AM, Brett Zamirbret...@yahoo.com wrote: Thanks, that's helpful. Still would be nice to have item-* though... Well, your idea for custom item-* attributes is just a way to more concisely embed triples of non-visible data. You already have a mechanism for embedding non-visible triples (meta orlink), so the new method needs some decent benefits to justify the duplication of functionality. HTML could have been created without attributes too--but if one is going to use it frequently enough, concision is a big selling point (as is non-redundant styleability). Additionally, while we recognize that non-visible data is sometimes necessary to embed, we'd like to discourage its use as much as possible (in general, non-visible data rots much faster). One way to do that is to make the syntax slightly cumbersome or ugly - when you really need it, you can use it, but your aesthetic sense will keep it from being the first tool you reach for. So, making it easier or prettier to embed non-visible triples is actually something we'd like to avoid if we can. People who are going to go to the trouble of adding semantics which do nothing for visual rendering are probably going to have some idea of what they are doing. And if there is an adequately convenient method, they will have the chance to learn from experience about the right balance. And is my idea really encouraging hidden meta-data? Even in my own example of using water damage: span itemprop=damage item-agent=water So blurry /span ...this is allowing some extensibility (by allowing an indefinite number of attributes), but conceptually it is not so different from: span itemprop=water-damage So blurry /span ...which no one is calling hidden. My suggestion is actually /helping/ avoid hidden meta tags not directly associated with an element encapsulating visible text. Note, though, that Microdata or RDFa may not be quite appropriate for this kind of thing. You're not marking up data triples for later extraction as independent data - you're doing in-band annotations of the document itself. As such, a different mechanism may be more appropriate, such as your original design of using a custom markup language in XML, or using custom attributes in HTML. There's no particular reason for these sorts of things to be readable by arbitrary robots; it's sufficient to design for ones that know exactly what they're reading and looking for. With the likes of Google offering Microdata-aware searches, I think it makes a whole lot of sense to allow rich documents such as TEI ones to enter as regular document citizens of the web, whereby the limited resources of such specialized semantic communities can leverage the general purpose and better-supported services such as Google's Microdata tool, while also having their documents editable within the likes of WYSIWYG HTML text editors, and stored on sites such as discussion forums or wikis where only HTML may be allowed and supported. I think such a focus would also enable the TEI community to benefit from reusing search-engine-recognized schemas where available, as well as helping the web community build new schemas for the unique needs of encoding academic texts. I haven't yet looked into TEI's metadata scheme, but is the TEI metadata actually something that needs to be known to search engines? The one example you've presented in your emails, annotating that some parts of a transcription were water-damaged (and thus presumably possibly inaccurate?), isn't something useful for search engines, but only for humans looking at the document as a whole. It could be useful to a search engine. If I remembered that some text was water-damaged, I could specify that I only wanted to look for water-damaged text (with the TEI itemtype). But I used the water damage example to show something very minute and concrete. I could have given examples about how one wished to search for more frequent use cases such as finding a particular component of a structured bibliography, or find all quotations attributed to a particular author. Search engines could of course be employed not only for searching the whole web, but for searching a particular site. If most of the other metadata is similar, then the only reason to use Microdata is to potentially make it easier to read/embed data via Microdata-aware WYSIWYG editors (are there any?). Or, possibly, to use Microdata-extraction tools. My point about editors was that relative to TEI XML, TEI in HTML could be put into editors. Relative to other approaches like using data-*, it would not be a particular advantage, outside of the fact that data-* is meant only to be used by the specific site, not for republishing by others. For example, if a publisher of a TEI Bible encoded a ton of semantics, using data-* to do so would let the document be previewable in a text editor or shared
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Fri, 17 Jun 2011, ilya goberman wrote: I do not really understand what specify the request to happen with credentials really mean. Can someone explain or point to an example? It just means that the user's relevant cookies are included in the request. My opinion is that it should be the same for the XHR and EventSource and should also be backward compatible. They are. We currently generate Access-Control-Allow-Origin:* in the server responses for the XHR requests to allow cross-domain calls (and do not really do anything beyond that) and I hope it will not be broken with these new credentials validation changes. For EventSource (and for XHR when withCredentials is set) you need to explicitly give the origin that was included in the request in the response, instead of just using *. Since EventSource is only useful when the server is dynamic, this isn't really a big deal. Just put the relevant logic in whatever script is generating the event stream. On Sat, 18 Jun 2011, ilya goberman wrote: I wish I could read what changes to XHR/ EventSource are done in some spec... It's all public: http://www.whatwg.org/specs/web-apps/current-work/complete/comms.html#server-sent-events http://html5.org/tools/web-apps-tracker?from=6254to=6255 On Sat, 18 Jun 2011, Anne van Kesteren wrote: I think we should change CORS to allow * for credentialed requests. People have already asked for that. I don't have a strong opinion on this (though I do think the concern that authors will shoot themselves in the foot if we don't have at least a small barrier here is a valid one). Currently, the changes to img, video, audio, and EventSource are agnostic to this. That would also allow dropping the crossorigin= attribute which complicates the request model for the elements it is applicable to a lot. (Too much, in my opinion.) (I designed CORS in such a way it could be used for img and such without the need to introduce new syntax.) We still need crossorigin= actually because some sites break if you send an Origin: header on image requests. On Sat, 18 Jun 2011, Olli Pettay wrote: It is a very strange API inconsistency if XHR defaults to credentials=false, but EventSource to credentials=true. EventSource doesn't really make much sense with credentials=false most of the time, so it seems simpler for authors to just not bother asking them to set it each time explicitly. On Tue, 21 Jun 2011, Per-Erik Brodin wrote: What I am saying is that currently CORS defines custom request headers and that can be interpreted as all headers that are set by the API implementations (such as Last-Event-ID set by EventSource but not including the headers normally set by the HTTP loader, such as Host), regardless if they are author supplied or not. Custom request headers is defined unambiguously as A list of custom headers for the request. Empty, unless explicitly set. Since EventSource does not explicitly set it, it is empty for EventSource's purposes. On Tue, 21 Jun 2011, Per-Erik Brodin wrote: On 2011-06-20 21:59, Ian Hickson wrote: According to the CORS specification, a request is not to be terminated even when the resource sharing check fails. However, when using CORS with EventSource I think it may be justified since the response is typically not returned right away. Not sure what you mean here. Could you elaborate? I misread the sentence Do not actually terminate the request. in the CORS spec as applying to both the resource sharing check pass and failure cases. Ok. No change is require here then right? The Cache-Control request header used with EventSource is not in the list of simple request headers and a preflight request is not really an option here in my opinion. Not sure what you mean by simple request headers. The Cache-Control header isn't a custom header, so it doesn't affect whether you use a preflight or not. I've clarified the spec. OK, is Last-Event-ID also not a custom header then? There are no custom headers here. Why would you think there are? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
