- From: Matt Giuca <notifications@github.com>
- Date: Tue, 03 Oct 2017 03:47:15 +0000 (UTC)
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/620@github.com>
Most of the manifest fields (see below) are specified as trimming their string values during processing. The question has come up as to whether to remove this logic (spun off from #611 --- it makes it much easier to specify the manifest in WebIDL without the trimming logic). However it's really a separate issue. Removing this logic would be a breaking change to the Web, so we need an analysis of existing manifests to see if this is going to break. It's also open to debate whether this change is desirable. The fields that currently trim are: - dir - lang - name - short_name - description - display - orientation - categories - iarc_rating_id - Image.src - Image.type - Image.platform - ServiceWorker.src - ServiceWorker.scope - ServiceWorker.type - Application.platform - Application.url - Application.id - Application.min_version There are numerous other fields (mostly URLs) that aren't trimmed, so the set of fields that are trimmed seems quite arbitrary (e.g., why is ServiceWorker.scope trimmed, but not scope?). I would say we should divide the strings into user-facing and non-user-facing. The user-facing ones (name, short_name, description, categories) probably should still be trimmed, since it doesn't make sense for an application name to have leading or trailing spaces. The spec doesn't necessarily have to explicitly trim them; this could just be left up to the platform. The other fields really have no business being trimmed. URLs, enum values, and so on, should just be an error if they contain spaces at all. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/620
Received on Tuesday, 3 October 2017 03:47:38 UTC