Yes, actually I had the same thoughts. Also, the case of http-equiv="X-UA-Compatible" is not important, so it is 100% fine to get rid of http-equiv completely.
17. Apr 2016 00:13 by [email protected]: > > I was thinking of just leaving 'http-equiv' out of the > attribute list! Is there a reason to prefer <meta > http-equiv="X-UA-Compatible"> over setting that header in the HTTP > response? > > The character set is already set to UTF-8 in the HTTP response, so > I think the first <meta> below is not important. > > The viewport example is the one I'm already aware of. It's a bit > lame that the same can't be done with CSS or an HTTP response header! > > On 04/15/2016 08:24 PM, > [email protected]> wrote: > > >> The most obvious choice is whitelisting, at least for for >> http-equiv, because the specification is relatively complex. >> >> https://www.w3.org/TR/html401/struct/global.html#edef-META >> >> Whitelisting for name attribute might be less usable, but I do not >> know whether it is important to add keywords for search engines >> these days. Probably not. >> >> https://www.w3.org/TR/html401/appendix/notes.html#recs >> >> Personally I am interested to see support for the use cases below. >> <meta charset="utf-8"/> >> <meta http-equiv="X-UA-Compatible" content="IE=edge"/> >> <meta name="viewport" content="width=device-width, >> initial-scale=1.0"/> >> >> At the moment I just define meta as >> val meta : unit -> tag [Nam = string, Content = string, >> Http_equiv = string, Charset = string] head [] [] [] >> >> >> 16. Apr 2016 10:35 by >> [email protected]>> : >> >> >>> Someone recently requested a nice way to include a <meta >>> name="viewport" content="..."> tag in Ur/Web. It doesn't seem safe >>> to expose <meta> in its most general form, with type [string] for >>> each attribute, since it seems like browsers could interpret >>> those strings in quite arbitrary ways, which goes against Ur/Web's >>> philosophy about implicit interpretation of strings as programs. >>> >>> Are there any opinions, then, on the right way to expose this >>> tag? >>> >>> My first thought is to add an application-level whitelist of >>> which <meta> names are allowed, just as with HTTP header names. >>> Then the 'content' attribute could be exposed as [string], while >>> the 'name' attribute would have an abstract type of allowable >>> names. The programmer would need to be careful not to whitelist >>> names that can lead to mayhem. >>> >>
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
